Outsider's Dev Story

Stay Hungry. Stay Foolish. Don't Be Satisfied.

기술 뉴스 #129 : 19-07-01

웹개발 관련

  • The cost of JavaScript in 2019 : V8에서 JavaScript의 처리 성능을 높이는 방법에 관해 설명한 글이다. JavaScript 파일이 50 ~ 100KB가 넘으면 작은 번들로 나누는 것이 다운로드도 빠르고 CPU와 메모리 비용도 줄일 수 있고 JavaScript 파일의 실행 시간을 줄이고 인라인 스크립트는 메인 스레드가 담당하기 때문에 너무 많이 사용하지 말라고 하고 있다. 왜 이러한 부분이 실제로 빠른지도 설명하고 있는데 V8에 메인 스레드 외에 워커 스레드로 JavaScript의 실행을 나누어서 처리하기 때문에 이를 활용하면 파싱/컴파일 시간을 줄일 수 있다고 한다.(영어)
  • Every Layout : CSS로 웹사이트의 레이아웃을 구성할 때 종류별로 어떤 문제가 있고 해결방법이 무엇인지를 자세하게 설명하는 글이다. 현재는 아래로 쌓는 Stack과 가운데 큰 영역이 있는 Cover 레이아웃, 사이드바 레이아웃을 볼 수 있고 다른 레이아웃은 아직 열리지 않은 상태이다. CSS를 전문적으로 하지 않다 보니 상황에 급급하게 해결할 때가 많은데 여러 조건을 고려해서 해결책을 제시하고 있다는 점에서 유용해 보인다.(영어)
  • THE SECRET OF GOOD ELECTRON APPS : Electron 앱을 만들 때 메모리도 적게 쓰고 속도를 빠르게 하기 위해서 main 프로세스와 renderer 프로세스 뒤에 Node 프로세스를 띄워서 처리하는 방식을 설명하고 그 예제 소스를 공유한 글이다. 개발 과정에서는 Node 백엔드 프로세스를 별도의 창에 띄워서 개발자 도구로 쉽게 디버깅할 수 있다.(영어)

그 밖의 개발 관련

  • Stop Writing Code Comments : 코드에 남긴 코멘트는 좋지 않은 코드라는 신호이므로 코멘트가 있으면 코드를 더 명확하게 수정해야지 코멘트를 남기지 말아야 한다는 글이다. 코멘트는 보통 코드가 명확하지 않아서 설명하는 것이므로 실패를 덮는 경우가 많고 코드에 이미 표현한 것을 다시 코멘트로 남기거나 너무 긴 함수를 작성해서 코멘트로 설명하는 것도 추상화의 실패를 의미하므로 차라리 함수로 쪼개는 게 낫다고 얘기하는데 나도 코멘트를 좋아하지 않는 편이라 동감하는 내용이다. 현실 코드는 더 복잡하긴 하겠지만 예시도 잘 나와 있어서 이해하기 좋고 마지막으로 정규표현식에 대한 설명이나 경고 등 코멘트를 남겨도 괜찮을 때도 설명하고 있다.(영어)
  • 엔터프라이즈에서의 오픈 소스 : 기업에서 오픈소스를 어떻게 도입하고 사용하면서 오픈소스 커뮤니티를 다시 어떻게 돕고 있는지 등 회사에서 오픈소스를 사용하는 전략을 AWS에서 30여 페이지의 무료 이북으로 만들어서 배포했다.(한국어)
  • Announcing the Visual Studio Code Installer for Java : Visual Studio Code에서 Java 개발을 할 수 있게 환경을 구성해 주는 인스톨러를 Microsoft에서 공개했다.(한국어)
  • Announcing Envoy Mobile : Envoy Proxy의 기능을 iOS(Swift)와 Android(Kotlin)에서 사용할 수 있는 Envoy Mobile 라이브러리의 프리뷰 버전이 공개되었다. 직접 사용해 보지는 못했지만, 글에 따르면 크로스 플랫폼에서 protobuf 코드 생성을 통해 네트워크를 추상화해서 사용하면서 캐싱이나 스트리밍, Envoy 정책 등을 이용할 수 있다고 한다.(영어)

인프라 관련

  • [번역] 쿠버네티스 네트워킹 이해하기#1: Pods : 쿠버네스트에서 Pod은 서로 간에 통신을 할 수 있는데 여러 호스트 간에 이러한 통신 문제를 해결하기 위해서 쿠버네티스가 오버레이 네트워크를 어떻게 구성해서 사용하는가를 설명하는 글이다. 기본적으로 Docker를 사용할 때 구성되는 네트워크부터 여러 노드 간에 어떤 문제가 있어서 오버레이 네트워크가 필요한지가 나와 있다. 2편, 3편도 있다.(한국어)
  • Lambda@Edge와 CF Invalidation : AWS의 CloudFront 엣지 서버에서 실행되는 Lambda@Edge를 이용해서 들어오는 이미지를 on-the-fly로 리사이징해서 사용자에게 제공하고 지워진 이미지는 더는 제공하지 않도록 S3에서 이미지가 지워졌을 때 이벤트를 Lambda와 연결해서 CDN의 캐시를 제거하는 작업을 설명하고 있다.(한국어)
  • Kubernetes의 Elasticsearch : Elastic에서 Elasticsearch와 kibana를 Kubernetes 클러스터에서 쉽게 배포해서 사용/관리할 수 있도록 Elastic Cloud on Kubernetes(ECK)를 공개했다.(한국어)
  • Kubernetes Context in iTerm2’s Status Bar : Kubernetes에서 현재 사용 중인 컨텍스트를 iTerm2의 상태 바에 표시해서 주는 방법을 설명하고 있다.(영어)

볼만한 링크

  • WHAT I LEARNED CO-FOUNDING DRIBBBLE : 디자인 공유 사이트인 Dribbble을 공동 창업자인 Dan Cederholm이 Dribbble을 창업하고 10년 동안 운영한 뒤 물러나기로 하면서 그동안 배운 20가지를 정리해서 쓴 글이다. 공동 창업자를 신중하게 고르고 티셔츠로 초기 사용자를 모으면서 처음 100명의 사용자의 피드백이 왜 중요했는지 등이 나와 있다. Dribbble이 좋아하는 서비스라서 그런지 그동안의 발전 과정 등도 보여서 재미있게 읽었다. "Designing for designers is… difficult."라는 말이 재미있다.(영어)
  • A Day in the Life of a Core Maintainer : Gatsby 메인테이너가 하루를 어떻게 보내는지를 설명한 글이다. 글의 내용만 보면 풀타임 오픈소스 개발자로 보이는데 오픈소스 프로젝트에서 생산성 있는 작업이 무엇인지 설명하고 아침에 일어나서 이슈와 PR을 리뷰하면서 하루를 시작하고 간단한 일을 위주로 처리하다가 많은 사람에게 의미 있는 영향을 줄 수 있는 작업 위주로 집중해서 작업하면서 방해받지 않도록 슬랙 등의 알림을 끈다고 한다. 약간 긴 글이고 풀타임 메인테이너라 약간 다를 수는 있지만 오픈소스 메인테이너들이 프로젝트 개발을 어떻게 하는지 엿볼 수 있다.(영어)
  • 페이스북 암호화폐 Libra 백서 (번역) : 페이스북에서 공개한 암호화폐 Libra의 백서를 번역한 글이다.(한국어)

IT 업계 뉴스

프로젝트

  • Sublette : 이흥섭님이 만든 컬러 스킴으로 iTerm2, Hyper, Jetbrain, VS code 등에 설정해서 사용할 수 있다.
  • Eva Design System : 커스텀 가능한 디자인 컴포넌트 시스템으로 UI 컴포넌트와 아이콘 셋이 포함되어 있고 Sketch 파일과 Angular, React 컴포넌트 코드까지 함께 제공하고 있다.
  • OpenAPI Generator : OpenAPI 2/3 버전 문서에서 클라이언트 라이브러리, 서버 스텁, 문서를 생성해 주는 도구.
  • Just : Microsoft에서 만든 JavaScript Task 라이브러리.
  • ktop : 터미널에서 Kubernetes의 Pod과 CPU, 메모리를 볼 수 있는 대시보드.

버전 업데이트

2019/07/01 23:45 2019/07/01 23:45

Terraform Enterprise의 원격 상태 관리

작년 HashiConf에서 원격 상태 관리를 무료로 제공하겠다고 발표한 뒤 지난달 Terraform Cloud Remote State Management가 공개되었다.

Terraform Cloud를 보면 현재 Terraform의 상태관리 기능을 지원하고 Plan/Apply도 지원할 예정이라고 나오고 있다. 원래 Terraform Enterprise가 기업용 솔루션이고 이런 기능도 모두 Terraform Enterprise에서 제공하던 기능이었는데 이 기능이 무료 사용자에게도 열린 것이다. 사이트를 보면 Terraform Enterprise와 Terraform Cloud가 혼용돼서 사용되는 느낌이 있다.

Terraform을 사용하면 상태를 관리하는 .tfstate 파일이 협업할 때 중요한데 이를 같이 사용할 수 있도록 S3 등에 원격으로 올려서 사용하는 것이 일반적이다. 이 기능을 Terraform 자체에서 무료로 제공한다고 보면 된다.

회원 가입

회원 가입을 하면 다른 팀에 합류하거나(관리자가 등록을 해주어야 한다) 새로운 조직을 만들어서 사용해야 한다.

회원 가입후 안내 화면

처음에는 조직이 아예 없으므로 개인용 조직을 만들어서 사용하면 된다.

새로운 조직 생성

이제 만들어진 워크스페이스에 진입하는데 아래처럼 처음에는 아무것도 나타나지 않는다.

비어있는 워크스페이스 목록

실제로 이 화면에서는 아무것도 할 수가 없다. 아직 웹서비스의 편의성은 부족한 부분이 보이는데 조직에 이메일로 새로운 사용자를 초대할 수 없다거나(팀원이 가입한 뒤 아이디를 알려주어야 한다) 처음 가입 시 기본 개인용 조직이 생기지 않다거나 여기서처럼 웹에서는 새로운 워크스페이스를 생성하는 기능 등이 없다.

환경 설정

이 워크스페이스를 이용하려면 Terraform v0.11.13 이상과 API를 사용하기 위한 엑세스 토큰이 필요하다. Terraform의 최신 버전이 0.12이고 0.11.x 에서는 크게 호환성 문제는 없으므로 사용하는 데 큰 문제는 없어 보이고 엑세스 토큰은 Settings > API Tokens에서 아래와 같이 생성할 수 있다.

엑세스 토큰 생성

이 토큰은 ~/.terraformrc 파일에 다음과 같이 설정하면 된다.

credentials "app.terraform.io" {
    token = "YOUR_ACCESS_TOKEN"
}

이제 Terraform 파일에서 S3가 아닌 테라폼 클라우드로 설정을 하면 된다.

terraform {
  backend "remote" {
    organization = "outsider"
    workspaces {
      name = "state-test"
    }
  }
}

여기서 organization는 앞에서 생성한 조직명을 넣어야 하고 workspaces.name은 이제 사용할 이름을 지정하면 된다. 뒤에서 보겠지만 여기서 지정하는 이름별로 워크스페이스가 생긴다. 즉, 이 이름별로 .tfstate를 관리하는 것이다. 그래서 이름 지정이 중요하긴 한데 약간 썼을 때는 작명 규칙은 불편하게 느껴졌다. 워크스페이스 이름이 URL 경로가 되기 때문에 URL 중간 경로로 사용할 수 있는 문자가 가능한 거로 보인다. 그래서 /등을 사용할 수 없다.

그래도 아래 S3보다 더 설정이 더 간단한 것을 알 수 있다.

terraform {
  backend "s3" {
    bucket     = "terraform.state"
    key        = "ec2/terraform.tfstate"
    region     = "ap-northeast-1"
    encrypt    = true
    lock_table = "TerraformStateLock"
    acl        = "bucket-owner-full-control"
  }
}

이제 terraform init을 하면 초기화되면서 원격 백엔드를 설정하는 것을 볼 수 있다.

$ terraform init

Initializing the backend...

Successfully configured the backend "remote"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "aws" (terraform-providers/aws) 2.16.0...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Terraform Enterprise에 접속하면 지정한 워크스페이스가 새로 생성된 것을 볼 수가 있다.

새로 생성된 워크스페이스

설정이 끝났으니 평소처럼 terraform plan/terraform apply를 사용하면 된다.

장점

실제로 좀 사용해 보니 S3를 쓸 때에 비해 장점이 좀 있다.

설정이 간단하다. HCL 코드 자체도 간단하지만 처음 Terraform을 설정할 때 나 같은 경우 S3 버킷을 생성하고(버저닝이나 Lock 설정을 포함해서) .tfstate 파일을 S3 버킷에 업로드하면서 사용하는데 이런 번거로운 작업 없이 원격 백엔드 지정만 하면 바로 사용할 수 있다.

상태파일 변경 히스토리

변경사항을 쉽게 볼 수 있다. 실제로 작업을 하면서 .tfstate의 변경사항을 살펴보는 경우는 많지 않기는 하지만 Terraform의 특성상 코드가 master 브랜치에 들어오기 전에 인프라는 이미 적용되어 .tfstate는 변경되는 경우가 많다. Pull Request라도 올라와 있으면 좀 낫지만, 실수로라도 수정한 테라폼 코드를 공유하지 않았는데 변경사항이 생겼다면 누가 언제 변경했는지 봐야 하는 경우가 있는데 S3에서는 이게 정말 힘든데 Terraform Enterprise에서는 아주 쉽게 볼 수 있다.

그리고 보통 Terraform으로 관리하는 인프라와 아닌 인프라가 섞여 있는 경우가 많으므로 코드는 변경하지 않았지만, plan에서 변경사항이 생겼을 때 상태 파일에 누가 변경을 가한 것인지 AWS 콘솔에서 바꾸었는지 찾아볼 때도 편할 것으로 보인다. .tfstate가 Git 커밋 같은 것은 아니라서 상태 메시지는 위처럼 알 수 없게 나타나지만, 최소한 누가 언제 변경했는지는 알 수 있다.

상태파일의 변경 diff

각 변경사항을 눌러서 들어가면 상태 파일의 변경내역도 쉽게 확인할 수 있다.(.tfstate 파일은 보기에 좀 더 복잡하긴 하지만...)

워크스페이스의 최종 실행상태와 Lock 여부

사소하지만 다른 사람이 락을 건 경우에는 웹에서 확인할 수도 있다. 화면에 "Local execution"은 최종 실행이 어디서 되었는지 나오는 것 같은데 원래 Terraform Enterprise가 서비스 내에서도 apply를 할 수 있어서 나오는 것 같다. 무료로 쓸 때는 아직 그 기능이 없어서 항상 "Local execution"이라고 나온다. 웹 인터페이스에서 Lock을 걸 수도 있는데 언제 써야 할지는 잘 모르겠다.

TFE(Terraform Enterprise)에 장애가 생겼을 때가 걱정되지만 S3보다는 편해서 일단 HashiCorp를 믿고 TFE를 위주로 써보려고 한다. 조만간 plan/apply 기능도 제공한다고 하니 기대 중이다.

2019/06/27 21:06 2019/06/27 21:06