코드 리뷰(Code Review)의 목적에 대해서 이야기해 본 적이 있다. 코드 리뷰의 목적에 대해 말하면서 다음 번에는 코드 리뷰를 잘 하는 방법에 대해 이야기 하기로 했다. 그래서 코드 리뷰를 잘하기 위한 방법에 대해 공유해 보고자 한다. 가장 먼저 하고 싶은 이야기는 '숙제 검사 이야기'다. 코드 리뷰를 처음 접하는 사람들이 리뷰를 숙제 검사로 받아들이는 경우가 많았다. 어떤 일이 주어지면 그 것에 대한 기능을 개발하고나서 결과를 검사해 달라는 의미로 리뷰를 요청하였다. 보통 이런 경우는 몇 가지 특징이 있다. 예상 일정의 마감 직전에 풀 리퀘스트(PR; Pull Request)가 올라온다. 그리고 거기에는 꽤 많은 양의 코드가 포함되어 있다. 또한 코드에 대한 설명이 별로 없다. 보통 이런 코드 ..
2021년, AWS에서 제공하는 카오스 엔지니어링 서비스인 장애 주입 실험기(Fault Injection Simulator, FIS)를 출시하였다. 그래서 서비스 장애 주입 실험기를 활용하는 카오스 엔지니어링 테라폼 예제(https://github.com/Young-ook/terraform-aws-fis/)를 만들었다. EC2 오토스케일링 그룹, EKS 컨테이너 클러스터, RDS 데이터베이스 클러스터, Redis 클러스터, VPC 네트워크를 대상으로 장애를 주입하는 카오스 엔지니어링을 직접 실습 해볼 수 있다.카오스 엔지니어링(Chaos Engineering)이라는 이름만 들었다면, 여러가지 상상이 떠오를 것이다. 아니다, 어쩌면 모든 사람이 같은 생각을 떠 올렸을 수도 있다. 우주가 탄생하기 전 혼돈의..
멀티 클라우드(Multi-Cloud)는 문자를 그대로 해석했을 때, 여러 개의 클라우드 컴퓨팅 환경을 뜻한다. 보통 이런 경우, 대부분 규모가 큰 업체를 떠올리게 된다. 멀티 클라우드 전략이라는 말을 들었을 때 아마도 아마존(Amazon), 구글(Google), 마이크로소프트(Microsoft)를 떠올렸을 것이다. 레드햇(Redhat), 오라클(Oracle) 까지 생각해보면 클라우드 제공 업체들은 많다. 그러나 멀티 클라우드가 이러한 여러 업체를 두 개 이상 사용하는 것만을 의미하지는 않는다. 많이 이상하게 들리겠지만 AWS(Amazon Web Services)에서 EC2 인스턴스와 ECS 컨테이너(Container)를 복합적으로 사용하는 것도 멀티 클라우드라고 볼 수 있다. 클라우드라는 것은 서비스를 ..
지금은, 할야드(Halyard)를 이용해서 쉽고 간편하게, 사용자인증, 데크 및 게이트 노출을 처리하고 있다. 지금은 아래 설정 방법을 직접 할 필요는 없다. 할야드를 사용하면 알아서 적절한 위치에 관련 설정을 잘 적용해 주기 때문이다. 다음은 OAuth2 인증을 적용하는 예제를 보여준다. 공식적으로는 구글(Google), 깃헙(Github), 애저(Azure)를 지원하고 있지만, 다른 사용자정보 제공자(IdP, Identity Provider)도 사용할 수 있다. 그럴 경우에는 PROVIDER 부분에 OTHER라고 입력한다. 그 외 나머지 정보는 프로바이더에서 제공하는 URL을 알맞게 연결해주면 된다. CLIENT_ID=myClientId CLIENT_SECRET=myClientSecret PROVID..
버전 관리(Version Control)는 문서, 프로그램, 웹 페이지 등 어떠한 형태의 정보 집합이든지 그 변화를 기록하고 관리하는 것을 뜻한다. 이렇게 변화의 내용을 관리하면, 결과물의 편집본과 최종본을 쉽게 관리할 수 있으며, 여러 사람이 함께 공동으로 작업할 수 있게 해준다. 아마도 대부분의 사람들이 파일(File)의 이름을 바꿔가면서 이력관리 해본 경험이 있을 것이다. 이 방법이 가장 직관적이며 쉽게 떠올 릴 수 있는 방법이기 때문이다. 그러나 회사에서 여러 사람들과 공동의 작업을 진행하는 경우에도 같은 방법을 사용하게 되면 많은 불편함을 겪게 된다. 누가 작업하고 있는 것이 최종인지 확인이 어렵기 때문이다. 취합본이라는 메일을 받아 본 기억을 떠올려 보자. 현재 자신이 작업 중인 문서와 메일로..
2018년 초 AI(Artificial Intelligence)기반의 새로운 과제를 시작하면서 인프라스트럭처 애즈 코드(Infrastructure as Code)를 적용할 것인지 논의하였다. 소규모 과제의 경우에는 인프라스트럭처 애즈 코드를 적용하고 싶지 않다는 주장이 나왔기 때문이었다. 인프라스트럭처를 모두 코드로 만들어서 관리하는 장점은 알겠지만, 규모가 너무 작아서 작업자가 GUI 도구로 간단하게 만들어 버리는 것이 더 빠른 경우도 있다는 주장이었다. 또한 그 정도 간단한 과제라면 장애복구도 매우 간단하게 수행할 수 있는데, 이를 위해 테라폼(Terraform) 또는 클라우드 포메이션(CloudFormation)을 이용하여 코드를 만들고 검증하는 과정이 오히려 부담스럽다는 의견이었다. 배보다 배꼽이..
스핀에커(Spinnaker)에서 AWS ECR(Elastic Container Registry)를 연결하기 위해서는 주기적으로 인증정보를 갱신해 주어야 하는 불편함이 있었다. 보안을 위해서 그렇게 해야 하는 것은 당연했지만, 사이드카(Side-car) 어플리케이션을 추가로 설치해서 주기적으로 실행해 주도록 처리하는 것은 번거로운 일이었다. 그러다가 2018년 9월 말에 AWS에서 이 문제를 해결하기 시작했다. 그래서 특별한 조치를 추가하지 않더라도 AWS CLI와 IAM 권한을 이용하여 ECR에 접근할 수 있도록 개선하였다. 1.11.3 이상에서 동작한다. 그 이하 버전에서는 오류가 발생한다.hal config provider docker-registry account add ecr-demo \ --ad..
스핀에커(Spinnaker)의 핵심 기능은 카나리 배포(Canary Deployment), 블루/그린 배포(Blue/Green Deployment)를 쉽게 지원한다는 것이다. 스핀에커에는 오르카(Orca)라는 마이크로서비스(Microservice)가 있으며, 배포를 포함한 전체 파이프라인을 관리하는 오케스트레이션(Orchestration) 기능을 담당한다. 그래서 흔히 지속적 전달(Continuous Delivery)도구를 이야기하면서 여전히 젠킨스(Jenkins)나 GitLab CI, Circle CI를 이야기한다. 그러나 그 어느 것도 오르카만큼 최신 배포 기술을 잘 지원하지 못한다. 만약 VM(Virtual Machine)환경 기반으로 블루/그린 배포를 하고 싶은 경우, 스핀에커를 제외한 다른 도구..
스핀에커(Spinnaker)의 권한관리를 위해 피아트 서비스(Fiat Service)가 추가되었다. 스핀에커가 처음에 공개되었을 때는 사용자 인증과 권환관리 기능이 없었다. 그러더니 게이트(Gate)에 OAuth2를 이용한 인증 기능이 추가되었고, 다음으로 피아트가 생기면서 GitHub, LDAP, SAML등의 기술을 활용하여 권한관리를 할 수 있는 기능이 추가되었다. 역할 제공자(Role Providers) 피아트는 역할(Role)을 직접 다루지 않는다. 대신 조직(Organization) 또는 그룹(Group)의 정보를 제공하는 외부 Solution과 연동하여 이 문제를 해결하다. 다시말해서 관리자는 역할 제공자(Role Provider) 중 한가지를 이용하여 조직과 그 속에 속한 사용자를 직접 관리..
스핀에커를 생성하고 관리할 수 있는 테라폼 모듈 프로젝트 저장소(https://github.com/Young-ook/terraform-aws-spinnaker) 에서 구체적인 내용을 확인할 수 있다. 스핀에커 테라폼 모듈 외에도 AWS 계정을 스핀에커에서 관리할 수 있도록 등록하는 방법, Amazon EKS 클러스터를 생성하고 스핀에커에서 관리할 수 있도록 등록하는 방법, 카오스 엔지니어링을 위한 카오스 몽키(Chaos Monkey) 연동방법 등 스핀에커 모범 사례 예제가 제공된다. Netflix 에서 2016년에 꽤 발칙한 소프트웨어(Software)를 공개했다. 스핀에커(Spinnaker, https://www.spinnaker.io) 라는 도구인데, 공개되자마자 많은 사람들의 관심을 받았다. 스핀에..