catpark's something new

회사에서 윈도우 노트북을 사용한다. 그래서 우분투 특히 bash를 사용하려면 아래와 같은 방법을 사용했다.

1. vmware, virtual box에 우분투를 설치해서 사용
   • guest os를 깔아서 사용하기 때문에 무겁게 느껴진다...
   • 사실 desktop보다는(bash가 아닌 GUI가 들어있으니 느려도 그려러니...) server를 사용하기 때문에 가볍게 구동되길 바라서인지 더 무겁게 느껴지는 것 같다.
2. build server에 ssh, smb를 붙여서 사용
   • ssh, smb 콤비는 내가 정말 사랑하는 조합
   • 빌드 서버는 보통 랩탑보다 사양이 좋다. 그래서 dev 서버나 도커 빌드 및 실행 서버로 사용한다.
   • 다만 사내망은 분리되어 있어서 외부 접속이 어렵다.
     • 자택근무를 하다보니 외부접속이 안되는 것이 더 아쉽다.
3. Linux Containers on windows 10
   • Hyper-V에서 실행되는 LinuxKit 기반 가상 컴퓨터를 사용하여 실행
     • docker 클라이언트는 window 데스크탑에서 실행되지만 linux VM상의 Docker daemon을 호출합니다.Moby VM의 linux 컨테이너
       

       

   • Linux Containers with Hyper-V isolation
     • Hyper-V isolation 기능이 있는 linux컨테이너는 컨테이너를 실행하기에 충분한 OS만으로 최적화된 linux VM에서 각 linux 컨테이너를 실행
       • microsoft/nanoserver, openjdk:8-jdk-alpine같은 tiny build를 말하는 것 같다.
         

         

   • 참조 : https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/linux-containers
4. WSL (Windows Subsystem For Linux)
   • 진짜 Ubuntu가 설치되니까 실제 개발 환경과 유사하다.
     • 1주 정도 써보니 좀 불편하네요. 정신 건강을 위해서는 그냥 vm환경으로 하라는 조언도 있습니다. ^^;
   • vmware나 virtual box와는 다르게 부팅 없이 바로 실행된다.
   • 느린 IO 속도, 커널이 다 호환되지 않아서 일부 app(nmap등)이 실행되지 않는다.
     • https://docs.microsoft.com/ko-kr/windows/wsl/troubleshooting
     • 이외에 위와 같은 문제들이 있다고 한다.
     • 그 문제들 중에 openssh 문제는 아래와 같이 지우고 다시 깔아야 한다.
       • sudo apt purge openssh
       • sudo apt install openssh
   • 하지만 단점들이 개선된 WSL2가 windows 참가자 프로그램에 리뷰중이니 정식 배포가 조만간 될 수 있을 것 같다. 그전에 먼저 사용하고 싶으신 분은 아래 링크에서 설치 해보시길....
     • https://docs.microsoft.com/ko-kr/windows/wsl/wsl2-install

어제는 WSL로 docker, ssh를 사용해서 내 개인 서버의 let's encrypt 인증서를 와일드 카드로 갱신했다.

docker도 잘 돌고 (https://medium.com/rkttu/wsl%EC%97%90%EC%84%9C-native-docker-%EC%8B%A4%ED%96%89%ED%95%98%EA%B8%B0-ff75b1627a87) ssh를 통해 remote 환경에서도 작업하는데 문제가

없었다. => 이렇게는 현재 wsl에서는 동작하지 않는다.

https://blog.jayway.com/2017/04/19/running-docker-on-bash-on-windows/에 나와 있는데로 docker 데몬은 window것을 쓰고 wsl이 docker client가 되는 방법이다.

win10 1607버전 이상이라고 하니 3~4년 전에 있었는데 이제야 알았다. 되니까... 이러고 다른 방법은 고민을 안했던거 같다. wsl뿐만 아니라 다른 것들도 현실에 안주하지 말고 더 좋은 방법은 없는지 고민해 보는게 필요할 듯 하다.

p.s. 여담인데 wsl2는 아직 preview 버전에서 동작하는데 불안정 버전이라 그런지 이런 상황도 있었다. 쫄지 말자. ㅎ

WSL2는 가상 네트워크 스위치 설정이 잘 안되어서 결국 못쓰게 되었다.

참고글 https://m.blog.naver.com/seongjin0526/221778212779

Docker에서도 settings에서 WSL2를 반영 할 수 있도록 지원하고 있다. 다만 아직 preview이다. (2020.05.15)

현재 WSL1으로 사용하는 용도

• ADB
  • logcat에 grep을 쓸 수 있다는건 큰 축복
• git cli
  • git gui tool보다는 cli를 사용하는데 윈도우 환경보다는 리눅스가 편하다.
  • tip
    • c 드라이브는 /mnt/c
    • WSL git clone issue - https://stackoverflow.com/questions/52846489/cant-clone-repository-from-mounted-drive

1. 아키텍트 역할 정의

이러한 조직이 MSA로 가기 위하여 가장 고민해야 할 부분은 아키텍트들이다. 개발자들은 대부분 개발을 하고 공통 프레임 워크를 사용하고, 강력한 표준 준수를 규정으로 정의하여 자율성을 최대한 적게 가져갔던 Monolithic 아키텍처 대비 개발자가 거의 모든 일을 알아서 해야 하는 그리고 자 율도가 많은 MSA 특성에 맞는 시스템을 구현하기 위하여 아키텍트의 역할은 많은 변화가 필요하다.
"Building microservices Sam Newman" 책에서는 아키텍트의 역할을 "진화적 아키텍트"라는 용어를 사용하여 정의하였다.
진화적인 아키텍트는 [원칙과 실천]으로 분리하여 아키텍트 역할을 정의해야 한다고 했다.

• 원칙 : 변하지 않는 것으로 한 프로젝트 혹은 한 회사의 아키텍처 원칙을 정의한다. 예를 들면 우리의 아키텍처는 "외부 의존성은 낮추고, 복잡성은 제거 해야 하며, 인터페이스와 데이터의 흐름은 일관성을 유지한다" 라는 원칙을 세웠다고 하 자.
• 실천 : 위의 원칙을 지키고자 하는 여러 아키텍처를 활용하는 것이다. 예를 들면 "표준 인터페이스는 Rest API, 통합 DB 는 사용하지 않으나 업무 종류별 회사 표준의 DB를 활용 한다" 등등. 각 시스템에 맞는 그러나 표준은 준수하는 실천을 해 야 하는 것이다.

아키텍트는 이렇게 원칙을 정의하고 실천은 알아서 하되, 이를 원칙에 맞게 조율하고 준수하게 하는 통합 아키텍트와 각 서비스에서 아키텍처를 구현하는 서비스 영역내 아키텍트로 구분하여 역할을 만들어야 한다.
[출처]MSA 어플리케이션 구축 시 조직 구성은 어떻게 해야 할까요?|작성자리니

원칙을 정하고 원칙에 의해 아키텍처를 적용하면 진행방향이 흔들리지 않을 것입니다.

2. TDD

1. 프로그램을 개발하기 전에 먼저 테스트 코드를 작성하는 것...이라고 하지만 개인적인 생각은 꼭 "먼저"일 필요는 없다이다. 이것이 test code가 필요없다는 것이 아니라 프로그래밍 시작이건 중간이건 끝나고던 배포전에만 testcode가 작성되어 있다면 된다는 것이다. 그러 나 먼저 하는 것을 추천한다. 항상 할 일을 미루면 프로그램 중에도 찝찝하고 한 번 미룬건 계속 미루기 쉽상이기 때문이다.
2. TDD를 통해서 얻고자 하는 최종 목적은 잘 동작하는 깔끔한 코드(clean code)이다. 이는 유지보수의 편의성, 가독성, 안정성등의 여러가 지 의미를 내포한다.
3. TDD 진행
   1. 과정 질문(Ask) : 테스트 작성을 통해 시스템에 질문한다.(테스트에 실패할만한 질문을 해야한다.)
   2. 응답(Response) : 테스트를 통과하는 코드를 작성해서 질문에 대답한다. (테스트에 통과할 최소의 코드만을 작성해야 한다.)
   3. 정제(Refine) : 아이디어를 통합하고, 불필요한 코드를 제거하고 모호한것을 명확히한다.
   4. 반복(Repeat) : 다음 질문을 통해 계속해서 진행해 나간다.

3. CI/CD Automation

1. CI (Continuous Integration)
   1. 개발자가 자신의 코드를 중앙 코드와 통합하면 자동으로 빌드되고 report가 생성된다.
   2. 이때 위의 TDD에서 작성한 test code의 coverage에 따라 영향을 받는다.
2. CD (Continuous Delivery)
   1. 사실상 CI의 연장선, CD를 하려면 CI가 선행되어야 한다고 봐도 무방하다.
   2. 현재 우리 회사는 Jenkins가 사용되고 있으므로 검토대상 1호이다.

4. Container Management

1. Kubernetes같은 orchestration tool이 하는 일이다.
2. 하지만 현실적으로 cloud의 기능을 사용해야 할 듯 하다.
3. resiliency 복원력 정도로 해석할 수 있다. 다음 이야기 하는 service mesh와 함께 문제가 되는 container를 다시 동작하도록 하는 기능이 있다.

5. Service Mesh

1. 밑에 그림 처럼 outer gateway가 아닌 inner gateway에서 적용되어야 할 부분이다.
2. AWS App Mesh
   1. https://docs.aws.amazon.com/ko_kr/app-mesh/latest/userguide/what-is-app-mesh.html
3. Azure service Fabric Mesh
   1. https://docs.microsoft.com/ko-kr/azure/service-fabric-mesh/service-fabric-mesh-overview
4. Spring Cloud Consul
   1. Consul은 full featured control plane을 제공하는 service mesh solution.
   2. service discovery, health checking, key-value store, secure service communication, multi datacenter
   3. https://www.consul.io/intro/index.html
      1. Consul vs. Other Software
         1. 다른 소프트웨어와의 비교를 consul입장에서 정리한 것 같다.
5. Istio
   1. load balancing, service registry, API management등의 기능이 있는 차세대 service mesh
   2. 그럼 흔히 알고 있는 netflix OSS의 service mesh와는 뭐가 다르길래 차세대라고 하는건지?
      아래 그림을 참고하자.
      

      

      1. 비즈니스 로직에 service mesh 관련 코드가 있는지 없는지가 큰 차이다.
      2. 항상 코드에 섞여 있는 것은 (특히 인프라 부분) 좋은 상황은 아니다.
      3. 그래서 properties나 yaml이라도 사용하여 소스 코드와 분리하려고 하지 않는가.

6. Distributed Tracing

1. AWS App Mesh
   1. https://docs.aws.amazon.com/ko_kr/xray/latest/devguide/xray-guide.pdf
2. Azure Application Insight
   1. https://docs.microsoft.com/ko-kr/azure/azure-monitor/app/app-insights-overview
3. Spring Sleuth - zipkin을 이용
   1. trace, span ID를 이용하여 remote logging을 하고 micro service간의 log들을 추적할 수 있다.
   2. 위의 두 서비스에 비해 분명 개발 및 운영도 해야 되어서 손이 많이 가지만 가격적인 측면도 무시 못한다.
   3. 이러한 tracing서버는 한 번 구축 하면 다른 서비스도 적용 가능해서 어느 정도 서비스가 많아 지면 손익 변곡점을 넘기게 마련이다. 중장기적인 플랜을 기준으로 판단이 필요하다.

그냥 간단하게 생각 나는 것들을 정리해 보았습니다. log에 대한 visualize라든가 ELK를 이용하는 것들이 더 생각 하는데 조금씩 살을 덧붙여 처음 시작할 때는 고려사항 목록으로, 진행하면서는 check list로 활용하도록 해볼 생각 입니다.

https://prev.rust-lang.org/ko-KR/faq.html

이렇게 정리된 language가 있었던가???