Cloud Computing On Demand

간만에 Swift 환경으로 넘어오니 묵혀있던 애플 M1 환경에서의 에러 공습이 시작되었습니다. cocoapod 설치까지는 잘 진행되었으나 필요한 의존성을 Podfile에 기술하고 설치하는 작업에서 문제가 생겼습니다. 설치하고자 한 의존성은 Alamofire 였습니다. 

# Podfile
target 'ch6' do
  use_frameworks!
  pod 'Alamofire', '~> 5.4'
end

에러 메세지도 한번 보고나서 트러블 슈팅을 진행해 보겠습니다. M1 을 쓰기 전이었다면 다른 케이스를 먼저 의심했겠지만, M1을 쓰기 시작한 후부터 이런 단순한 작업에서 에러가 발생하면 일단 M1 환경 문제로 보는 습관이 생겼습니다 ㅎㅎ

% pod install
Analyzing dependencies
/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/library.rb:275: [BUG] Bus Error at 0x00000001012d4000
ruby 2.6.3p62 (2019-04-16 revision 67580) [universal.arm64e-darwin20]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   for more details.
Don't forget to include the above Crash Report log file in bug reports.

-- Control frame information -----------------------------------------------
c:0049 p:---- s:0307 e:000306 CFUNC  :attach
c:0048 p:0258 s:0301 e:000300 METHOD /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/library.rb:275
c:0047 p:0050 s:0281 e:000280 CLASS  /Library/Ruby/Gems/2.6.0/gems/ethon-0.14.0/lib/ethon/libc.rb:17
...
..
..
...
  653 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/autopointer.rb
  654 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/variadic.rb
  655 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/enum.rb
  656 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/version.rb
  657 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi/ffi.rb
  658 /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi.rb

[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: https://www.ruby-lang.org/bugreport.html

[IMPORTANT]
Don't forget to include the Crash Report log file under
DiagnosticReports directory in bug reports.

zsh: abort      pod install

이제 정답을 찾기 위해 열심히 구글링을 했고 두가지 정도의 방법을 찾았습니다.

방법#1. cocoapod 를 실행하는 터미널을 Rosetta 로 실행하기

M1 에서 호환성 문제를 해결하기 위해 가장 먼저 사용해 볼 수 있는 것이 Rosetta 입니다. iTerm 을 터미널 클라이언트로 쓰고 있기 때문에 "파인더 > 응용프로그램"에서 iTerm을 찾아 속성에서 Rosetta 를 켜주면 됩니다. 

이제 동작중인 터미널을 종료하고 pod install 을 다시 수행해봅니다. 하지만 여전히 에러가 발생합니다. 

% pod install
Analyzing dependencies

[!] Automatically assigning platform `iOS` with version `15.0` on target `ch6` because no platform was specified. Please specify a platform for this target in your Podfile. See `https://guides.cocoapods.org/syntax/podfile.html#platform`.
Traceback (most recent call last):
	45: from /usr/local/bin/pod:23:in `<main>'
	44: from /usr/local/bin/pod:23:in `load'
	43: from /Library/Ruby/Gems/2.6.0/gems/cocoapods-1.11.2/bin/pod:55:in `<top (required)>'
	42: from /Library/Ruby/Gems/2.6.0/gems/cocoapods-1.11.2/lib/cocoapods/command.rb:52:in `run'
	41: from /Library/Ruby/Gems/2.6.0/gems/claide-1.0.3/lib/claide/command.rb:334:in `run'
    ...
    ..
    ..
    ...
    	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle, 9): no suitable image found.  Did find: (LoadError)
	/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle: mach-o, but wrong architecture
	/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle: mach-o, but wrong architecture - /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle
	36: from /usr/local/bin/pod:23:in `<main>'
	35: from /usr/local/bin/pod:23:in `load'
    ...
    ..
    ..
    ...
    	 3: from /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi.rb:2:in `<top (required)>'
	 2: from /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi.rb:5:in `rescue in <top (required)>'
	 1: from /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require'
/System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/rubygems/core_ext/kernel_require.rb:54:in `require': dlopen(/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle, 9): no suitable image found.  Did find: (LoadError)
	/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle: mach-o, but wrong architecture
	/Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle: mach-o, but wrong architecture - /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.3/lib/ffi_c.bundle

에러 메세지를 참고하여 ffi에 문제가 있다는 것을 확인하고 재설치를 진행해 봅니다. 이후 다시 pod install 을 수행하면 문제가 해결된다고 합니다. 제 경우는 아쉽게도...

% sudo gem install ffi
% pod install

방법#2. Ruby FFI 라이브러리 업데이트 후 재설치

에러 메세지에 아키텍쳐 관련한 내용이 계속 나오는 것에 착안하여 사람들이 올려둔 방법중 아키텍쳐 관련된 것들을 사용해 보았습니다. ffi를 설치할 때 아키텍쳐를 x86_64 로 지정하여 설치하는 방식입니다. (M1은 arm 기반이라 arch 명령을 수행해보면 arm64 라고 나옵니다)

% sudo arch -x86_64 gem install ffi
Password:
Fetching ffi-1.15.4.gem
Building native extensions. This could take a while...
Successfully installed ffi-1.15.4
Parsing documentation for ffi-1.15.4
Installing ri documentation for ffi-1.15.4
Done installing documentation for ffi after 9 seconds
1 gem installed

설치만 하면 pod install 이 동작할까요? 아닙니다. 그냥 pod install 명령을 사용하면 아키텍쳐가 arm64 로 인식되기 때문에 여전히 아키텍쳐 관련한 호환성 문제가 발생합니다. 대신 명령 앞에 아키텍쳐를 지정해서 실행해 보도록 하겠습니다. 

% arch -x86_64 pod install
Analyzing dependencies
Downloading dependencies
Installing Alamofire (5.4.4)
Generating Pods project
Integrating client project
Pod installation complete! There is 1 dependency from the Podfile and 1 total pod installed.

잘 되는군요. :-)

근래에 가장 각광받는 자격시험이 쿠버네티스 Kubenetes 관련된 자격증일 것 같습니다. 리눅스 파운데이션에서 주관하는 쿠버네티스 시험은 크게 3가지 종류인데요, 최근 모 조사기관에서 발표했던 내용에 따르면 모든 자격 시험들 중 CKA(Certified Kubenetes Administrator)에 대한 관심이 가장 많다고 합니다.

쿠버네티스 관련된 시험들은 생각보다 가격이 좀 있기 때문에 할인 쿠폰이 유통(?)될 때 미리 시험을 등록해 두는 것이 좋다고 합니다. 시험을 등록하면 목표 일정을 설정하는 효과가 있으니... k8s를 학습해 나가는데 좋은 모티베이션이 될 것이라고 생각됩니다. 시험 등록일 기준으로 1년간 리스케쥴링이 가능하고 무료 재시험도 한차례 제공되니 사실상 부담도 없을 것 같습니다.

이번에 유통되는 할인 코드는 SCHOOL25 입니다. 리눅스 파운데이션의 시험 등록 페이지에서 쿠폰 코드 Coupon Code 항목에 입력해 주시면 됩니다. 환율이 요즘 급격히 변화하고 있어서 전표 매입 타이밍에 따라 실제 비용은 좀 차이가 생기겠지만 1160원 기준으로 계산해 보면 33만원 정도인 것 같네요. 할인 받아도 싸지는 않은 느낌입니다 ㅎㅎ

여튼, 쿠버네티스 자격시험 준비하고 계신다면 이번 할인 쿠폰을 잘 활용해 보시기 바랍니다. 꾸준히(?) 할인 쿠폰이 나오니 Apply 를 눌러서 쿠폰 적용이 안된다면 한달 정도 여기저기 또 검색해 보시면 할인 쿠폰을 발견하실 수 있을거라 생각합니다. 마지막으로 개인적으로 추천드리는 k8s 강의 링크 하나 드려 봅니다. 강의도 할인 중이라 대략 16,000원 정도로 저렴하네요!

(추가. 2022.09)
참고로, 저 역시 위 강의를 듣고 2022년 9월 시험에 합격했습니다. 시험 합격 후기와 시험 꿀팁, 가상 시험 환경에 대한 이야기는 다음의 포스팅에서 간략하게 정리를 해보았습니다. 시험을 준비하고 계시다면 조금이나마 도움이 될 것 같습니다!

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급 받을 수 있습니다

여기까지 잘 따라오셨나요? Subscription filter도 설정했으니 이제 끝이야!! 라고 하기에는 아직 할 일이 조금 남아 있습니다. 필요한 준비는 대충 되었지만 실제로 Elasticsearch에 접근하기 위한 계정 매핑 작업이 남아 있습니다. 사실 어떤 계정으로 ES Cluster가 제공하는 Kibana를 쓸 것이냐는 선택이 폭이 무척 넓고 구현 방법도 다양합니다.

특히 보안관점에서 탄탄해지려면 이 포스팅 시리즈의 내용만으로는 부족합니다. 다만 우리의 목적은 빠르게 로그를 적재해 보는 것이기 때문에 앞선 포스팅들에서도 간단하게 IP를 통해 접근을 제어하고 별도로 만든 특정 Master Account로 로그인하도록 했었습니다.

여기에 더하여 AWS가 ES Cluster에 데이터를 적재할 수 있도록 하기 위해서 Lambda를 위해 생성한 IAM Role을 ES Cluster의 권한에 매핑하도록 하겠습니다.

IAM Role을 Kibana에 매핑하기

먼저 Kibana에 생성했던 Master Account로 로그인을 합니다. 좌측 메뉴의 `Open Distro for Elasticsearch > Security` 메뉴에 진입하면 7개의 서브 메뉴가 나옵니다. 그 중 `Roles`를 선택하고 쓰기 권한이 있는 특정한 Role을 찾거나 만들도록 하겠습니다.

간단한 시험을 위해 여기서는 `all_access` Role을 사용하도록 하겠습니다. 네, 보안적으로 좋은 프랙티스는 아닙니다!

ES Cluster의 all_access Role에 Lambda에 부여한 AWS IAM Role의 ARN을 매핑해 줘야 합니다. 잠시 AWS의 IAM 관리 화면으로 넘어가서 Role화면으로 이동하겠습니다.

ES Cluster의 Role인지 IAM의 Role인지 헷갈리지 않도록 유의하시기 바랍니다! IAM 관리 화면에서 앞서 생성한 Lambda용 Role을 찾아 해당 Role의 ARN을 복사하겠습니다.

복사한 ARN을 ES Cluster의 Kibana 화면에서 선택한 쓰기 권한이 있는 Role에 추가해 줍니다. Mapped Users 탭의 Manage mapping 버튼을 누르고 Backend Roles 에 ARN을 추가한다음 Map 버튼을 누릅니다. 에러가 발생하지 않았다면 문제가 없는 것입니다.

이제 거의 끝났습니다. 쓰기 권한이 있는 ES Cluster Role에 IAM Lambda Role이 연결되었기 때문에 로그가 클러스터에 적재되기 시작했을 겁니다. 만약 이렇게 했는데도 로그가 쌓이지 않는다면 권한 부여하는 과정에 잘못된 ARN을 복사해 왔을 가능성이 있습니다. 차근히 화면을 보면서 다시 설정하시면 문제 없을 것이라 생각합니다.

이제 `Index Management`로 이동하여 로그가 들어오는지 확인해 보겠습니다. CloudWatch Logs에서 보내는 로그의 기본 인덱스명은 cwl로 시작합니다. 아래와 같이 cwl로 시작하는 로그들이 들어오는게 보이는지 확인하겠습니다.

이제 좌측 메뉴의 `Kibana` 섹션에서 Discover 메뉴를 선택하고 인덱스 패턴을 만들어 보겠습니다. 여기부터는 ES 혹은 Kibana의 영역이기 때문에 더 자세한 설명은 생략하도록 하겠습니다. 인덱스 패턴까지 만들고 저장했다면 이제 로그를 쿼리할 수 있게 됩니다.

생성한 인덱스에 우리가 앞서 Subcription filter 생성시 지정했던 것처럼 Field 이름들이 잘 들어오고 있는지도 확인할 수 있습니다. 대략 보니 크게 문제 없어 보입니다. 눈치 채셨겠지만 filter 설정시 사용한 컬럼 이름들이 Kibana의 Field로 사용되기 때문에 적절한 키워드를 사용해 주시면 되겠습니다.

Kibana의 Discover 화면에서 최근 15분간의 데이터를 조회해 봤습니다. 네~ 무척 잘 들어오고 있습니다. 모자이크 처리를 해두긴 했지만 지정한 컬럼별로 데이터가 잘 꽂히고 있는 것을 확인할 수 있었습니다.

아직 실트래픽이 실리고 있지 않아 쿼리 규모가 아주 작습니다만 실제 사용자 트래픽을 수용할 때는 적절히 클러스터의 규모를 조정해 줄 필요가 있습니다.

Elasticsearch 에 데이터가 적재되지 않을때 트러블 슈팅

이렇게 고생해서 셋업을 했는데 ES 클러스터에 데이터가 적재되지 않는 경우 무척 난감하실겁니다. 리소스들을 다시 정리하는 것도 일이고... 어디서 잘못된 것인지 찾는것도 스트레스입니다.

대부분의 경우 AWS CloudWatch Logs 기술 문서와 ElasticSearch 기술 문서에 내용이 나와 있긴 하지만 그래도 잘 안되는 경우 아래의 문서를 참고하실 수 있습니다.

https://aws.amazon.com/ko/premiumsupport/knowledge-center/es-troubleshoot-cloudwatch-logs/

지금까지 4개의 포스팅을 통해 Route53의 DNS 쿼리 로그를 CloudWatch Logs와 Elasticsearch를 활용하여 적재하고 분석하는 환경을 만들어 봤습니다.

DNS 쿼리는 상용 서비스 단계에서 무척 많은 로그를 남기게 됩니다. 때문에 많은 기업들이 on-premise에서 활용하는 서비스용 Authoritative NS에 대해서는 평상시에 로그를 특별히 남기지 않는 경우도 많습니다.

AWS를 통해 Route53을 쓰는 것은 일종의 Managed DNS 또는 Managed GSLB를 쓰는 것ㅇ기 때문에 서버의 로그를 바로 획득하기 어렵습니다.

하지만 (돈을 조금 낸다면.. 속닥속닥..) 로그를 쉽게 적재하고 분석할 수 있는 방법이 제공되고 있으니 필요할 때 유용히 활용할 수 있으면 좋겠습니다. 시리즈 글은 아래의 링크들을 참고하시기 바랍니다!

본 블로그의 글들은 제휴 마케팅을 통해 소정의 수수료를 지급받을 수 있습니다.

플러터 환경을 새로 준비하다보면 이전에 맛보지(?) 못했던 다양한 에러를 만나곤 합니다. 특히 Java의 버전이 달라진 경우에 이같은 문제가 더 자주 발생합니다. 새로운 애플실리콘 M1 Mac 환경에서 플러터 개발 환경을 새로 셋업하다 만난 Java 에러에 대하여 해결 방법을 정리해 봅니다.

플러터 환경설치시 활용하게 되는 닥터(doctor)는 부족한 환경 설정을 쉽게 진단해주고 어떤 대응을 해야 하는지 알려주는 도구입니다. 문제는 가끔 여기서 알려준 대응 방법을 실행하는 것 자체가 문제가 되는 경우입니다. 오늘 겪은 이슈는 새롭게 플러터 환경 설정시 필요한 안드로이드 라이센스에 대한 동의 과정에서 발생했습니다. 

플러터 닥터의 메세지 살펴보기

안드로이드 스튜디오, 플러터 SDK를 설치한 후 flutter doctor를 수행하여 추가로 진행해야 하는 작업을 살펴보았습니다. 안드로이드 라이센스에 대한 동의가 필요하다고 하여 이 부분에 대한 안내에 따라 명령을 수행했습니다. 이전에 다른 노트북에서도 큰 문제 없이 안내된 명령을 복붙하는 것으로 충분했기에 안내된 명령을 실행했습니다. 그런데...

%  flutter doctor --android-licenses
Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/annotation/XmlSchema
	at com.android.repository.api.SchemaModule$SchemaModuleVersion.<init>(SchemaModule.java:156)
	at com.android.repository.api.SchemaModule.<init>(SchemaModule.java:75)
	at com.android.sdklib.repository.AndroidSdkHandler.<clinit>(AndroidSdkHandler.java:81)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:73)
	at com.android.sdklib.tool.sdkmanager.SdkManagerCli.main(SdkManagerCli.java:48)
Caused by: java.lang.ClassNotFoundException: javax.xml.bind.annotation.XmlSchema
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	... 5 more

이전에 만나보지 못했던 새로운 경험... 그것도 굉장히 기본적인 문제가 있는 것처럼 보이는 에러가 똬악 나타났습니다. Java 익셉션이라니... 더 이상의 안내가 없었기 때문에 구글링을 열심히 하여 몇 가지 단서를 찾았고 그 중 하나는 "안드로이드 SDK 커맨드라인 도구"의 설치 부재시 발생할 수 있다는 것이었습니다. 

안드로이드 SDK의 커맨드라인 툴킷 설치하기

안드로이드 SDK의 커맨드라인 툴킷을 설치하는 가장 간단한 방법은 안드로이드 스튜디오의 셋팅 메뉴를 이용하는 방법입니다. 안드로이드 스튜디오를 실행하고 왼쪽 <Customize> 메뉴를 선택하면 아랫쪽에 <All settings...> 메뉴가 보입니다. 메뉴를 선택합니다.

설정 화면이 열리면 <Appearance & Behavior> - <System Settings> - <Android SDK>메뉴를 선택하고 우측의 탭에서 <SDK Tools>를 선택합니다. 예상대로 커맨드라인 툴킷이 설치되어 있지 않은 것이 보입니다. 체크후 설치를 진행해 봅니다. 

안드로이드 라이센스 동의 작업 다시 해보기

100MB 정도 되는 패키지를 다운로드하고 설치하는 과정은 금세 끝납니다. 설치가 완료되었다면 다시 터미널 화면으로 이동하여 플러터 닥터를 이용해 안드로이드 라이센스 동의를 해보니 문제 없이 수행이 됩니다. 참고로 간혹 특정한 동의가 자동으로 되지 않는 경우가 있는데 라이센스 동의 명령을 이용시 상세 내용을 조회하면서 동의를 해주면 모든 라이센스에 동의가 진행됩니다. 

%  flutter doctor --android-licenses
All SDK package licenses accepted.======] 100% Computing updates...

이제 다시 한 번 플러터 닥터를 수행하여 필요한 절차를 살펴보겠습니다. 에러가 표시되던 Android toolchain 항목에 그린라이트가 들어온 것이 확인되네요!

간혹 새로운 장비에서 Dockerfile 을 이용하여 이미지를 빌드해야 하는 경우가 생깁니다. 늘 사용하던 장비와 빌드하던 이미지라면 특별히 문제가 생기지 않지만 새로운 오픈소스 코드나 다른 사람이 만들어둔 Dockerfile을 생각 없이 새 장비에서 빌드하다보면 에러 메세지로 당황하기 마련입니다. 

오늘도 어김 없이 새 장비에서 Dockerfile을 이용한 이미지 빌드 실패건을 겪었는데요 미래의 저를 위해 간단하게 내용을 정리해 봅니다. 한줄 요약을 하자면 Docker의 버전이 낮아서 발생한 문제였습니다. 

새로운 오픈소스를 Docker 이미지로 빌드후 구동하기 위해 소스코드를 클론하고 make docker 명령으로 이미지 빌드를 시도했습니다. go로 개발된 프로메테우스 익스포터류의 코드였는데요 잠시 빌드가 진행되는 듯 하더니 FROM으로 지정된 이미지의 포맷이 잘못되었다는 에러 메세지와 함께 빌드가 실패했습니다. 

$ make docker
docker build -t "akamai/akamai-gtm-metrics-exporter-linux-amd64:master" \
        -f ./Dockerfile \
        --build-arg ARCH="amd64" \
        --build-arg OS="linux" \
        ./
Sending build context to Docker daemon 15.25 MB
Step 1/8 : FROM docker.io/golang:1.16.6 AS builder
Error parsing reference: "docker.io/golang:1.16.6 AS builder" is not a valid repository/tag: invalid reference format
make: *** [common-docker-amd64] Error 1

도커 이미지가 없어서 그런가 생각해봤지만 docker image 명령을 쳐보면 이미지가 정상적으로 로컬 환경에 저장되어 있는 것이 확인되었습니다. 이미지의 빌드 넘버가 없어서 그런가하여 도커 허브에 들어가 golang 태그를 찾아봐도 분명 존재하는 태그였습니다.

$ docker images
REPOSITORY                                   TAG                 IMAGE ID            CREATED             SIZE
docker.io/golang                             1.16.6              028d102f774a        3 days ago          862 MB
docker.io/victoriametrics/victoria-metrics   latest              27ae96c3f0f7        2 weeks ago         23.5 MB
docker.io/prom/prometheus                    latest              9dfc442be98c        3 weeks ago         189 MB
docker.io/victoriametrics/vmagent            latest              4d8a8d15c6ec        4 weeks ago         20.4 MB
docker.io/prom/node-exporter                 latest              c19ae228f069        4 months ago        26 MB

문제는 도커의 버전이었습니다. 빌드하려던 Dockerfile의 내용을 꼼꼼히 살펴보지 않아 Dockerfile이 멀티 스테이지 빌드가 필요하다는 것을 미처 확인하지 못했던 것이죠. 멀티 스테이지 빌드는 경량 도커 이미지를 만들기 위한 방법으로 제공되는 빌드 방식이고 도커 17버전 이상에서 지원되는 것으로 확인됩니다. 도커를 새로운 버전으로 업데이트 하고 다시 빌드를 시도해 보았습니다.

// 설치된 버전 확인
$ docker --version
Docker version 1.13.1, build 7d71120/1.13.1

// 설치된 docker 삭제
$ sudo yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-engine
                  
// Community Edition 설치를 위한 repo 정보 추가
$ sudo yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

// 최신 버전의 docker 설치
$ sudo yum install docker-ce docker-ce-cli containerd.io

// docker daemon 구동
$ sudo systemctl start docker

// 설치된 버전 확인
$ docker --version
Docker version 20.10.7, build f0df350

// 이제 빌드가 잘 되네요!
$ make docker
docker build -t "akamai/akamai-gtm-metrics-exporter-linux-amd64:master" \
        -f ./Dockerfile \
        --build-arg ARCH="amd64" \
        --build-arg OS="linux" \
        ./
Sending build context to Docker daemon  15.25MB
Step 1/8 : FROM docker.io/golang:1.16.6 AS builder
1.16.6: Pulling from library/golang
Digest: sha256:4544ae57fc735d7e415603d194d9fb09589b8ad7acd4d66e928eabfb1ed85ff1
Status: Downloaded newer image for golang:1.16.6
 ---> 028d102f774a
Step 2/8 : WORKDIR /go/src/github.com/akamai/akamai-gtm-metrics-exporter
 ---> Running in dab4aaede8da
Removing intermediate container dab4aaede8da
...
..
...
Successfully built a005e3513fae
Successfully tagged akamai/akamai-gtm-metrics-exporter-linux-amd64:master

참 쉽죠!?

아마 대부분의 경우 리눅스 환경에 접근시 루트 권한이 아닌 계정을 쓰고 있을 겁니다. 이 환경에서 docker 명령을 쓰다보면 pull 등 기본적인 명령 수행시에도 permission denied 를 만나게 되어 sudo 를 남발해야 하는 경우가 종종 발생합니다. 조금더 쉽게 docker를 사용하고 작업을 수행하기 위해 간단한 사용자, 그룹 변경으로 문제를 회피하는 방법을 정리해 봅니다. 

제가 만났던 permission denied 는 docker pull #이미지# 를 수행하는 과정에 발생했습니다. 발생한 위치는 나름 정확하게 나와서 /var/run/docker.sock 파일에 대한 접근을 하는 과정에서 권한 문제가 발생한 것으로 확인됩니다.

$ docker pull victoriametrics/victoria-metrics
Using default tag: latest
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.26/images/create?fromImage=victoriametrics%2Fvictoria-metrics&tag=latest: dial unix /var/run/docker.sock: connect: permission denied

이 권한 문제는 /var/run/docker.sock 파일의 접근 권한이 root 사용자에게 한정되어 있기 때문에 발생합니다. 따라서 접근 권한을 낮추거나 실사용자가 포함된 그룹을 만들어 파일의 소유권을 변경하는 것이 가장 깔끔한 방법입니다. 

# root 사용자/그룹에게 접근 권한이 있습니다
$ ls -al /var/run/docker.sock
srw-rw---- 1 root root 0 Jul  8 16:35 /var/run/docker.sock

# docker 그룹을 새로 만들어 사용자($USER)를 docker 그룹에 추가후 파일의 권한을 변경합니다.
$ sudo /usr/sbin/groupadd -f docker
$ sudo /usr/sbin/usermod -aG docker $USER
$ sudo chown root:docker /var/run/docker.sock

# 변경후 권한은 이렇게 바뀌었습니다
$ ls -al /var/run/docker.sock
srw-rw---- 1 root docker 0 Jul  8 16:35 /var/run/docker.sock

이제 별 문제 없이 pull 할 수 있게 되었습니다. (만세)

$ docker pull victoriametrics/victoria-metrics
Using default tag: latest
Trying to pull repository docker.io/victoriametrics/victoria-metrics ...
latest: Pulling from docker.io/victoriametrics/victoria-metrics
5843afab3874: Pull complete
576d2fdb56fe: Pull complete
a4c69497911f: Pull complete
Digest: sha256:dedd22e46e72518f7944355dd6b236231948c6a24d60f7ca201a5c007013da64
Status: Downloaded newer image for docker.io/victoriametrics/victoria-metrics:latest

참고자료

CentOS7 환경인지 먼저 점검합니다.

$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)

운영체제의 패키지들을 최신 버전으로 업데이트 합니다. (선택사항)

$ sudo yum update

docker와 docker-registry 패키지를 설치합니다

$ sudo yum -y install docker docker-registry

설치된 docker를 재부팅시에도 자동 실행하도록 합니다 (선택사항)

$ sudo systemctl enable docker.service
Created symlink from /etc/systemd/system/multi-user.target.wants/docker.service to /usr/lib/systemd/system/docker.service.

docker 서비스를 실행하고 상태를 확인해 봅니다

$ sudo systemctl start docker.service
$ systemctl status docker.service
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2021-07-08 15:55:35 JST; 24s ago
     Docs: http://docs.docker.com
     ...

docker-registry에 등록된 이미지를 가져와서 실행해 봅니다

$ sudo docker pull centos
$ docker run -it centos /bin/bash

파이썬 장고가 제공하는 단위 테스트는 코드 배포전에 에러를 검출해 볼 수 있는 방법으로 무척 유용합니다. 젠킨스 빌드시에도 활용하여 자칫 로컬 환경과 원격 빌드/운영 환경의 차이에도 대응할 수 있어 장애를 막는 지름길이 되기도 합니다.

파이썬 장고의 단위 테스트를 구성해서 잘 사용하던 중, 갑자기 (원인은 알 수 없습니다 ㅜㅜ) TransactionManagementError와 함께 테스트가 지속적으로 실패하기 시작하여 열심히 구글링하고 삽질한 내용을 간략히 정리해 봅니다. 

장고 단위 테스트를 사용하기 위해서는 아래와 같은 코드를 만들게 됩니다. 참고로 코드는 장고 공식 문서에서 가져왔습니다. 이때, 실제 테스트를 수행하는 클래스는 매개변수로 TestCase 클래스의 인스턴스를 받게 됩니다. 아래의 코드에서는 TestCase 클래스를 가져왔네요.

import unittest
from django.test import Client

class SimpleTest(unittest.TestCase):
    def setUp(self):
        # Every test needs a client.
        self.client = Client()

    def test_details(self):
        # Issue a GET request.
        response = self.client.get('/customer/details/')

        # Check that the response is 200 OK.
        self.assertEqual(response.status_code, 200)

        # Check that the rendered context contains 5 customers.
        self.assertEqual(len(response.context['customers']), 5)

코드를 보면 실제 테스트 함수들이 클래스 내에 기술이 되어 있습니다. 제 경우 문제는 테스트 함수들이 데이터베이스에 대한 질의를 수행하는 코드를 호출하면서 발생했습니다. 일반적인 TestCase의 서브 클래스로는 데이터베이스 관련 코드를 수행하고 테스트 결과를 돌려주는데 문제가 있었습니다. 테스트가 수행되면서 발생한 에러는 아래와 같습니다.

raise TransactionManagementError(
django.db.transaction.TransactionManagementError: An error occurred in the current transaction. You can't execute queries until the end of the 'atomic' block.

이 에러 메세지가 참 얄미운게 내용이 좀 뭉뚱그려져 있습니다. 굉장히 명확한 에러이기 때문에 TestCase 클래스를 트랜잭션을 지원하는 것으로 변경하라고 하면 되었을 것을 저렇게 표현하고 있어서 애를 먹게 만들더군요. 이 문제에 대한 첫번째 접근은 장고 공식문서에서 가이드하는 TransactionTestCase 클래스의 사용입니다. 

제 경우는 장고 REST Framework 를 사용하고 있던 관계로 이쪽에서 필요한 클래스의 변경 작업을 진행했습니다. 기존에 에러가 발생하던 테스트 코드에서는 REST Framework가 제공하는 test 패키지의 APITestCase 클래스를 쓰고 있었습니다. 이 클래스를 APITransactionTestCase로 변경하니 에러가 말끔히 사라지고 테스트도 정상적으로 수행되기 시작했습니다.

# 기존
from rest_framework.test import APITestCase

# 변경
from rest_framework.test import APITransactionTestCase

TransactionManagementError로 검색을 하다보면 여러가지 문제 상황과 이에 대한 대처법들이 소개되고 있습니다. 가령 1) 테스트 테이블에 데이터를 피딩하는 과정에 문제였고 이를 수정하여 해결 했다는 분도 계셨고, 2) 테스트가 수행하는 코드 내에 try~except 구문이 사용되는 경우 transaction.atomic() 을 이용해서 코드를 변경해야 된다는 글도 있었습니다.

다양한 트러블슈팅 사례와 방법이 있는 것을 보면 에러 메세지가 조금 더 친절하게 출력되면서 원인을 빠르게 확인할 수 있었으면 어땠을까 하는 생각이 듭니다. 그래도 트러블슈팅을 하면서 또 파이썬에 대해, 장고에 대해 조금 더 알 수 있었기에 의미 없는 시간은 아니었던 것 같습니다!

파이썬과 관련하여 최근에 겪었던 다른 이슈들과 해결 방법은 아래의 글을 참고해 보시기 바랍니다!