AWS Sam with Golang

AWS Lambda 를 작성하는 방법, 정확하게는 Serverless 의 API 를 작성하는 방법으로 SAM 을 사용한다. 그런데, SAM 을 이용해서 Runtime 을 Golang 으로 하려고 할 경우에 잘 안되는 경우가 발생한다. 2023년 말에 변화가 있었다.

이 문서는 위 문서의 내용을 요약한 것이다.

Error: There are no Template options available to be selected.

SAM 명령어를 이용해 Golang 런타임으로 생성할려고 하면 다음과 같이 오류가 발생한다.

sam init --runtime go1.x error
ZSH
1
2
3
4
5
6
]$ sam init --runtime go1.x
Which template source would you like to use?
        1 - AWS Quick Start Templates
        2 - Custom Template Location
Choice: 1
Error: There are no Template options available to be selected.

SAM 명령어에 옵션으로 –runtime go1.x 를 지정하면 위와같은 오류가 발생한다. AWS 공식문서에 따르면 이제 go1.x 는 없어졌다. 대신에 provided.al2 를 사용해야 한다.

sam init --runtime provided.al2
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
]$ sam init --runtime provided.al2
Which template source would you like to use?
        1 - AWS Quick Start Templates
        2 - Custom Template Location
Choice: 1
 
Choose an AWS Quick Start application template
        1 - Hello World Example
        2 - Infrastructure event management
        3 - Multi-step workflow
        4 - Lambda Response Streaming
        5 - DynamoDB Example
Template: 1
 
Which runtime would you like to use?
        1 - go (provided.al2)
        2 - graalvm.java11 (provided.al2)
        3 - graalvm.java17 (provided.al2)
        4 - rust (provided.al2)
Runtime: 1

Template.yml 파일 변화

–runtime 옵션에 provided.al2 를 사용하면 template.yml 파일에도 변화가 생긴다.

template.yml
YAML
1
2
3
4
5
6
7
   Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Metadata:
      BuildMethod: go1.x
    Properties:
      CodeUri: hello-world/
      Handler: bootstrap
      Runtime: provided.al2

Metadata 가 추가 된다. Runtime 이야 옵션으로 제공한 그대로 인데, Handler 가 bootstrap 이다. 이것을 바꿔서는 안된다. 또, Runtime 을 provided.al2 로 할 경우에 Lambda 의 Go 바이너리 실행 파일의 이름은 반드시 bootstrap 이여야 한다.

실행파일 이름은 반드시 bootstrap

Golang 의 람다 실행파일은 반드시 bootstrap 이어야 한다. 따라서 다음과 같이 컴파일해야 한다.

Compiling for the provided.al2 runtime
ZSH
1
]$ GOARCH=amd64 GOOS=linux go build -o bootstrap main.go

bootstrap 이 아닌 경우에는 실행되지 않는다.

-tags lambda.norpc 빌드 옵션 추가

bootstrap 바이너리를 빌드할때에는 반드시 -tags lambda.norpc 를 주어야 한다. AWS 공식 문서에 따르면 go1.x 에서는 필요했지만 provided.al2 로 런타임이 변경되면서 rpc 가 필요 없어졌다고 한다. 따라서 빌드할때에는 반드시 norpc 가 되도록 옵션을 지정해 줘야 한다.

Removing the RPC dependency
ZSH
1
]$ GOARCH=amd64 GOOS=linux go build -tags lambda.norpc -o bootstrap main.go

변경사항이 많지는 않지만 위에 서술한 옵션들을 지키지 않을 경우에 문제가 된다. 실행파일 이름과 norpc 는 반드시 해줘야 하며 template.yml 에서도 필요한 내용이 있어야 한다. 그렇지 않으면 별것도 아닌 것으로 인해서 많은 시간을 허비하게 될 것이다.

Running a arm64 of guest on x86_64 host via kvm

최근들어 arm64 아키텍쳐가 인기가 많아졌다. 애플의 실리콘 반도체라고 불리는것도 arm64 기반이며 Windows 11 도 arm64 에서도 작동된다. 리눅스는 오래전부터 다양한 아키텍쳐로 포팅이되었기 때문에 arm64 를 위한 배포판도 다양하게 존재한다. 문제는 arm64 아키텍쳐를 경험하기 위해서 arm64 하드웨어가 있어야 했지만, 이제는 x86_64 기반의 가상머신을 이용하면 arm64 아키텍쳐를 게스트로 운영할 수 있다.

이 문서는 x86_64 기반 가상머신에서 arm64 아키텍쳐기반의 게스트를 실행하는 방법에 대해서 기술한 것이다.

x86_64 가상머신

x86_64 아키텍쳐 기반의 가상머신으로 리눅스 운영체제를 기반으로 KVM 을 활용하고 있다. GUI 툴로서 virt-manager, CLI 로는 virsh 를 활용해서 간단하게 게스트를 생성하고 운영하고 있다. arm64 아키텍쳐 게스트를 운영하기 위한 호스트로서 x86_64 아키텍쳐 기반 가상머신 스펙은 다음과 같다.

  • OS: Ubuntu 22.04
  • Kernel: 5.15.0-207.156.6.el9uek.x86_64
  • CPU: AMD Ryzen 7 2700X Eight-Core Processor

libvirt vs QEMU

arm64 아키텍쳐기반 게스트를 운영하기 위해서는 QEMU 를 사용해야 한다. QEMU 는 가상머신 에뮬레이터라고 생각하면 된다. 문제는 QEMU 는 CLI 기반만 제공한다.

반면에 libvirt 는 KVM/QEMU 등을 지원하는 일종의 핸들러 라이브러리고 생각하면 된다. libvirt 를 이용하면 xml 기반으로 게스트 관련 가상머신 스펙을 정의할 수 있으며 virt-manager 와같은 GUI 툴도 활용할 수 있다.

QEMU 에뮬레이터라고 했기 때문에 arm64 를 위한 QEMU 에뮬레이터를 설치하면 arm64 기반 게스트 운영체제를 운영할 수 있다. 다음과 같이 arm64 를 위한 QEMU 에뮬레이터를 설치해준다.

qemu-system-arm 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ sudo apt install qemu-system-arm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  guestfish guestmount libconfig9 libguestfs-perl libstring-shellquote-perl libsys-virt-perl libwin-hivex-perl libxml-parser-perl
  libxml-xpath-perl
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  qemu-efi-aarch64 qemu-efi-arm
Suggested packages:
  vde2
The following NEW packages will be installed:
  qemu-efi-aarch64 qemu-efi-arm qemu-system-arm
0 upgraded, 3 newly installed, 0 to remove and 2 not upgraded.
Need to get 15.8 MB of archives.
After this operation, 532 MB of additional disk space will be used.

위 패키지를 설치가 완료되면 다음과 같이 virt-manager 에서 게스트를 생성할때에 Architecture options 이 생긴다.

qemu-system-arm 패키지 설치후 virt-manager 에서 Architecture options 이 나타난다.

arm64 를 위한 지원 파일 생성(Optional)

Ubuntu22.04 에서는 이 과정이 필요하지 않다.

arm64 게스트 실행을 위해서 파일이 필요하다. 첫번째로 NVRAM 변수들을 저장하기 위한 플래쉬 볼륨(Flash volume) 을 생성해야 한다.

NVRAM 변수 저장을 위한 플래쉬 파일 생성
ZSH
1
]$ truncate -s 64m varstore.img

두번째로 ARM UEFI 펌웨어 파일이 필요하다.

ARM UEFI 펌웨어 파일 생성
ZSH
1
2
]$ truncate -s 64m efi.img
]$ dd if=/usr/share/qemu-efi-aarch64/QEMU_EFI.fd of=efi.img conv=notrunc

이제 필요한 사항은 모두 갖춰졌다.

Amazon Linux Arm64 이미지 실행

처음부터 Arm64 기반 OS 를 게스트로 설치하면서 생성할 수도 있다. 하지만 이미 있는 Arm64 기반 OS를 가져다 쓸 수도 있다. 여기서는 Amazon Linux 를 가져다 사용해 보도록 하겠다.

Amazon Linux 는 Amazon 이 AWS 서비스에서 사용할 목적으로 만든 배포판이다. 현재 Amazon Linux2 와 Amazon Linux3 등 다양한 버전을 제공한다. 최근 프로젝트가 Amazon Linux2 를 많이 사용하고 있어서 Amazon Linux2 Arm64 기반 OS 이미지를 게스트로 한번 실행 보도록 하겠다.

Amazon Linux2 는 다음과같이 다운로드 할 수 있다. 이미지 파일은  Amazon Linux 2 virtual machine images 에서 찾을 수 있다.

Amazon Linux2 다운로드 하기
ZSH
1
]$ curl -LJO https://cdn.amazonlinux.com/os-images/2.0.20240610.1/kvm-arm64/amzn2-kvm-2.0.20240610.1-arm64.xfs.gpt.qcow2

seed.iso 만들기

Amazon Linux2 는 기본적으로 ec2-user 라는 시스템 계정이 있으며, 로그인을 위해 패스워드 방식이 아닌 SSH 인증키 방식을 사용한다. 하지만 배포되는 이미지에 맞는 인증키가 따로 없기 때문에 부팅과정에서 이 부분을 변경하도록 해야하는데, 이를 위해서 seed.iso 를 만들어 게스트 OS 에 CD-ROM 에 넣어 부팅해준다. 이 부분에 대한 설명은 다음의 페이지에서 찾을 수 있다.

간단하게, 시스템 호스트 이름(나중에 변경하면 된다) 과 ec2-user 에 로그인 패스워드를 변경하도록 seed.iso 파일을 만들어 보도록 하겠다.

먼저 작업을 위한 디렉토리 seedconfig 만들고 meta-data, user-data 파일을 생성한다.

seedconfig 디렉토리 생성 및 meta-data, user-data 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
]$ mkdir seedconfig
]$ vim meta-data
local-hostname: amazonlinux.onprem
]$ vim user-data
#cloud-config
#vim:syntax=yaml
users:
# A user by the name `ec2-user` is created in the image by default.
  - default
chpasswd:
  list: |
    ec2-user:amazon
# In the above line, do not add any spaces after 'ec2-user:'.

로그인이 가능하도록 필요한 부분만 넣었다. 이제 다음과 같이 seed.iso 파일을 생성해 준다.

seed.iso 이미지 작성
ZSH
1
2
3
4
5
6
7
8
]$ genisoimage -output seed.iso -volid cidata -joliet -rock user-data meta-data
I: -input-charset not specified, using utf-8 (detected in locale settings)
Total translation table size: 0
Total rockridge attributes bytes: 331
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 0
183 extents written (0 MB)

virt-manager 로 Amazon Linux2 생성하기

이제 준비할 것들은 모두 갖췄다. virt-manager 를 이용해서 Amazon Linux2 를 구동해 보자.

새로운 게스트 생성하기

OS 이미지가 있기 때문에 Import 로 하고 Arm64 는 aarch64 로 선택, Machine Type 은 virt 다.

amazon linux2 이미지, 운영체제 종류 선택

다운로드 받은 amazon linux2 이미지와 운영체제 종류를 선택한다. 운영체제 종류를 잘 모르겠다면 Generic Linux 로 해도 된다.

Memory, Cpu 는 사양에 맞게 조절해주고 다음을 선택한다.

Customize configuration before install 필수

가상머신 이름을 지정하고 네트워크 선택을 한다음에 반드시 Customize configuration before install 를 체크해 준다. 그리고 Finish 를 하면 다음과 같은 화면이 나온다.

Firmware 를 Custom 선택

Firmware 를 Custom 으로 하고 no-secboot.fd 선택해 준다. 그리고 설치를 시작해 준다.

정상적으로 부팅

정상적으로 부팅이 된다. 로그인이 안되기 때문에 앞에서 만든 seed.iso 파일을 이용해야 한다. 이를 위해서 Amazon Linux2 게스트 OS 에 CD-ROM 하드웨어를 추가해 준다.

CD-ROM 하드웨어 추가

이제 VM 을 다시 시작시키면 seed.iso 에 user-data 에 설정한 ec2-user 의 패스워드로 로그인이 가능해 진다.

정상적으로 로그인 성공

정상적으로 로그인이 성공했다. ec2-user 는 기본적으로 sudoer 권한을 가지고 있기 때문에 sudo 를 이용해서 root 작업을 할 수 있다.

sshd 에 설정에서 패스워드 인증을 활성화 해준다.

/etc/ssh/sshd_config
diff
1
2
- 65 PasswordAuthentication no
+ 65 PasswordAuthentication yes

설정을 변경해 줬기 때문에 sshd 를 재시작 해준다.

이렇게 sshd 로 패스워드 인증방식을 활성화 했기 때문에 원격에서 접속도 가능해진다.

마지막으로 Amazon Linux2 게스트 를 셧다운 해주고 seed.iso 를 위한 CD-ROM 하드웨어를 삭제해준다.

systemctl –user 설정하기

systemctl 은 리눅스에 서비스 데몬을 설정하는 것과 유사하다. 과거 init script 를 systemd 로 전환하면서 만들어진 것인데, 문제는 시스템의 서비스 데몬 등록이라서 대부분 root 권한으로 실행된다. 만일 일반 사용자가 systemd 유닛으로 등록하기 위해서는 어떻게 해야 할까…

~/.config/systemd/user

사용자 홈디렉토리에 ~/.config/systemd/user 디렉토리를 생성한다. 이 디렉토리에 사용자 systemd 유닛 파일을 작성해야 한다.

test.service

systemd 유닛 파일의 확장자는 service 다. 그리고 반드시 다음과 같이 WantedBy 값을 default.target 으로 해줘야 한다. 가끔 multi-user.target 으로 하는 경우가 있는데, 이걸로 할 경우 부팅시에 자동으로 실행되지 않는다.

test.service
INI
1
2
[Install]
WantedBy=default.target

서비스 활성화

이제 다음과 같이 사용자 서비스를 활성화 해준다. 이렇게 함으로써 부팅시에 자동으로 서비스가 시작된다.

서비스 활성화
ZSH
1
]$ systemctl --user enable test.service

이렇게 세팅을 하게되면 리눅스 서버가 부팅될때마다 사용자 서비스도 함께 자동으로 실행이 된다.

루트(root) 사용자 systemctl –user 사용하기

systemctl –user 는 일반사용자가 사용하는 명령어다. 하지만, root 사용자가 systemctl –user 명령어를 사용할 수 있을까? systemd 248 (released March 2021) 버전에서 -M username@ 옵션을 통해서 root 사용자가 명령어를 실행할 수 있다.

systemctl --user
ZSH
1
]# systemctl --user -M user1@ status myunit.service

참고

Start a systemd user service at boot

Run systemctl –user commands as root

REST 역사

현대의 소프트웨어 아키텍쳐로 인기가 있는, 아니 어쩌면 전부일 수도 있는 REST 에 대한 역사는 2000년으로 거슬러 올라간다. 시기적으로 그 당시에 한국에서는 IT 버블이라는 현상도 있었던 만큼 IT 관련 기업들이 많이 생겨나고 했던 때다.

2000년 당시를 회상해보면 웹 메일(Web Mail) 서비스를 기반으로 하는 포털들이 많이 있었다. 해외에서는 야후(Yahoo) 가 대표적이였고 마이크로소프트(Microsoft) 의 경우에도 Hotmail 과 함께 MSN 포털을 운영했었다. 국내에서는 다음(Daum) 이 한메일(Hanmail) 서비스를, 네이버(Naver)가 네이버 메일을 기반으로 포털로서 성장하던 때다. 아,,, 네이트도 있었는데, 당시 네이트는 네이트온(NateOn) 메신저가 인기가 있었던 것으로 기억한다.

그 당시에 해외에서도 그렇지만, 소프트웨어 아키텍쳐, 좀 더 정확하게는 이기종간에 데이터 전송을 위한 아키텍쳐로 SOAP(Simple Object Access Protocol) 를 기반으로 구축되었다. 물론 XMLRpc 도 존재했지만 엔터프라이즈 서비스에서는 SOAP 이 거의 표준처럼 사용되던 때였다.

캘리포니아 대학에 Roy Tomas Fielding 이라는 사람이 “Architectural Styles and the Design of Network-based Software Architectures” 논문을 쓴다. 여기에서 서버간의 데이터 전송에 대한 현재까지의 기술을 고찰하고 REST 에 대해서 처음으로 기술하게 된다. 이때가 2000년이였다.

REST 는 HTTP 를 기반으로 하기 때문에 서버의 기종과는 아무런 상관없이 데이터 전송이 가능했다. 더 군다나 그 구조자체가 SOAP 비해서는 매우 단순했기 때문에 데이터 전송에 대한 오버헤더도 줄었다.

이후에 REST 를 기반으로 구축한 업체들이 나타나게 되는데, eBay 가 그중 하나였다. eBay 는 그들의 파트너들에게 필요한 정부를 REST API 형태로 제공했던 것이다. 그때가 2000년 11월즘이였다고 한다. 이후에 Amazon, Flicker 등이 REST 기반 서비스를 제공하게 된다.

sam build 시 SSL 접속 에러 해결 방

다음과 같이 sam build 시 SSL 접속 에러가 발생할 수 있다.

sam build 오류
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
]$ sam build --template template.yaml
Starting Build use cache
Manifest file is changed (new hash: 3298f13049d19cffaa37ca931dd4d421) or dependency folder (.aws-sam\deps\53036498-ac29-43da-b665-6ca82b0cd06d) is missing for (HelloWorldFunction), downloading
dependencies and copying/building source
Building codeuri: C:\labs\aws\Source_Code\lambda\make-thumnail\hello_world runtime: python3.12 metadata: {} architecture: x86_64 functions: HelloWorldFunction
Running PythonPipBuilder:CleanUp
Running PythonPipBuilder:ResolveDependencies
 
Build Failed
Error: PythonPipBuilder:ResolveDependencies - WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.
  WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)'))': /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
  WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)'))': /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
  WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)'))': /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
  WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)'))': /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
  WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)'))': /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata
ERROR: Exception:
Traceback (most recent call last):
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 714, in urlopen
    httplib_response = self._make_request(
                       ^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 403, in _make_request
    self._validate_conn(conn)
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 1053, in _validate_conn
    conn.connect()
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connection.py", line 419, in connect
    self.sock = ssl_wrap_socket(
                ^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\util\ssl_.py", line 449, in ssl_wrap_socket
    ssl_sock = _ssl_wrap_socket_impl(
               ^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\util\ssl_.py", line 493, in _ssl_wrap_socket_impl
    return ssl_context.wrap_socket(sock, server_hostname=server_hostname)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\Python312\Lib\ssl.py", line 455, in wrap_socket
    return self.sslsocket_class._create(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\Python312\Lib\ssl.py", line 1046, in _create
    self.do_handshake()
  File "c:\Python312\Lib\ssl.py", line 1321, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)
 
During handling of the above exception, another exception occurred:
 
Traceback (most recent call last):
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\requests\adapters.py", line 486, in send
    resp = conn.urlopen(
           ^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 826, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 826, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 826, in urlopen
    return self.urlopen(
           ^^^^^^^^^^^^^
  [Previous line repeated 2 more times]
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\connectionpool.py", line 798, in urlopen
    retries = retries.increment(
              ^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\urllib3\util\retry.py", line 592, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
pip._vendor.urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1000)')))
 
During handling of the above exception, another exception occurred:
 
Traceback (most recent call last):
  File "c:\labs\aws\Lib\site-packages\pip\_internal\cli\base_command.py", line 180, in exc_logging_wrapper
    status = run_func(*args)
             ^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\cli\req_command.py", line 245, in wrapper
    return func(self, options, args)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\commands\download.py", line 132, in run
    requirement_set = resolver.resolve(reqs, check_supported_wheels=True)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\resolver.py", line 95, in resolve
    result = self._result = resolver.resolve(
                            ^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\resolvelib\resolvers.py", line 546, in resolve
    state = resolution.resolve(requirements, max_rounds=max_rounds)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\resolvelib\resolvers.py", line 397, in resolve
    self._add_to_criteria(self.state.criteria, r, parent=None)
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\resolvelib\resolvers.py", line 173, in _add_to_criteria
    if not criterion.candidates:
           ^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\resolvelib\structs.py", line 156, in __bool__
    return bool(self._sequence)
           ^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\found_candidates.py", line 155, in __bool__
    return any(self)
           ^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\found_candidates.py", line 143, in <genexpr>
    return (c for c in iterator if id(c) not in self._incompatible_ids)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\found_candidates.py", line 47, in _iter_built
    candidate = func()
                ^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\factory.py", line 182, in _make_candidate_from_link
    base: Optional[BaseCandidate] = self._make_base_candidate_from_link(
                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\factory.py", line 228, in _make_base_candidate_from_link
    self._link_candidate_cache[link] = LinkCandidate(
                                       ^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\candidates.py", line 290, in __init__
    super().__init__(
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\candidates.py", line 156, in __init__
    self.dist = self._prepare()
                ^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\candidates.py", line 222, in _prepare
    dist = self._prepare_distribution()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\resolution\resolvelib\candidates.py", line 301, in _prepare_distribution
    return preparer.prepare_linked_requirement(self._ireq, parallel_builds=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\operations\prepare.py", line 519, in prepare_linked_requirement
    metadata_dist = self._fetch_metadata_only(req)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\operations\prepare.py", line 371, in _fetch_metadata_only
    return self._fetch_metadata_using_link_data_attr(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\operations\prepare.py", line 391, in _fetch_metadata_using_link_data_attr
    metadata_file = get_http_url(
                    ^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\operations\prepare.py", line 109, in get_http_url
    from_path, content_type = download(link, temp_dir.path)
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\network\download.py", line 134, in __call__
    resp = _http_get_download(self._session, link)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\network\download.py", line 117, in _http_get_download
    resp = session.get(target_url, headers=HEADERS, stream=True)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\requests\sessions.py", line 602, in get
    return self.request("GET", url, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_internal\network\session.py", line 520, in request
    return super().request(method, url, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\requests\sessions.py", line 589, in request
    resp = self.send(prep, **send_kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\requests\sessions.py", line 703, in send
    r = adapter.send(request, **kwargs)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\cachecontrol\adapter.py", line 76, in send
    resp = super().send(request, stream, timeout, verify, cert, proxies)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "c:\labs\aws\Lib\site-packages\pip\_vendor\requests\adapters.py", line 517, in send
    raise SSLError(e, request=request)
pip._vendor.requests.exceptions.SSLError: HTTPSConnectionPool(host='files.pythonhosted.org', port=443): Max retries exceeded with url: /packages/70/8e/0e2d847013cb52cd35b38c009bb167a1a26b2ce6cd6965bf26b47bc0bf44/requests-2.31.0-py3-none-any.whl.metadata (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in
certificate chain (_ssl.c:1000)')))

이럴때에는 실행하는 위치에 pip.conf 파일을 다음과 같은 내용으로 만든다.

pip.conf 파일
INI
1
2
3
4
5
[global]
trusted-host = pypi.python.org
               pypi.org
               files.pythonhosted.org
               github.com

그리고 이 파일에 대한 환경변수를 지정해 준다.

PIP_CONFIG_FILE 환경변수 지정.
ZSH
1
set PIP_CONFIG_FILE=pip.conf

다시 sam build 를 수행하면 정상적으로 실행이 된다.

sam build 정상 수행.
ZSH
1
sam build --template template.yaml

만일 컨테이너를 사용한다면 다음과 같이 하면 된다.

Container 를 사용할때 sam build
ZSH
1
sam build --use-container --container-env-var PIP_CONFIG_FILE=pip.conf

Gitlab, Helm Chart CI 구축

Gitlab 은 Package Registry 라고 Helm 저장소를 지원한다. Helm Chart 를 만들고 이를 자동으로 빌드해서 Helm 저장소로 Push 하도록 만들어 보자.

Gitlab-runner

Gitlab 은 빌드를 위해서 Runner 라는 별도의 패키지를 소프트웨어를 제공한다. 이렇게 하면 서버를 여러대 둘 수 있고 각 빌드별 특성에 맞는 설정을 가진 Runner 를 셋업할 수 있다.

Helm 을 위해서는 당연히 helm 명령어가 설치되어 있어야 Runner 가 Helm 을 만들때 이용할 수 있다.

Download and Install
ZSH
1
2
3
]$ curl -fsSLO https://get.helm.sh/helm-v3.14.2-linux-amd64.tar.gz
]$ tar xvzf helm-v3.14.2-linux-amd64.tar.gz
]$ sudo mv helm /usr/local/bin/; sudo chmod +x /usr/local/bin/helm

gitlab-ci.yml

Gitlab 은 CI 를 위해서 gitlab-ci.yml 파일을 이용한다. 이 파일이 있으면 자동으로 인식해 CI 를 실행해 준다. 이 파일에서 해줘야 할 것은 다음과 같다.

  • git 소스코드 clone
  • helm package 제작
  • gitlab 의 package registry 에 push

여기서 한가지 짚고 넘어가야하는 것이 Gitlab-Runner 는 Gitlab 에 이름으로 등록을 하게 된다. 이것을 이용하기 위해서는 gitlab-ci.yml 에서 지정을 해줘야 한다. 뼈대는 대략 다음과 같다.

gitlab-ci.yml 뼈대
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
stages:
  - package
  - registry
 
helm-package:
  stage: package
  scripts:
    - ""
  artifacts:
    paths:
      - "*.tgz"
  after_script:
    - echo 'build success!'
  tags:
    - java-runner
  only:
    - main
 
helm-registry:
  stage: registry
  dependencies:
    - helm-package
  scripts:
    - ""
  tags:
    - java-runner
  only:
    - main

기본적인 틀은 위와 같다. only 는 git 브랜치가 main 을 대상으로 한다는 것을 지정한다. tags 는 Gitlab-Runner 를 말한다. 어떤 Runner 를 사용할지는 빌드환경에 따라 다르다. 위의 경우에는 java-runner 인데, Runner 의 타입이 shell 로 되어 있다. 그래서 앞에서 helm 명령어를 설치해줬다.

이제 stage:package 를 완성해야 한다. 다음과 같이 한다.

stage:package
1
2
3
4
5
6
7
8
9
10
11
12
13
helm-package:
  stage: package
  script:
    - "/usr/local/bin/helm package ."
  artifacts:
    paths:
      - "*.tgz"
  after_script:
    - echo 'build success!'
  tags:
    - java-runner
  only:
    - main

기본뼈대에서 script 부분에 helm 을 패키징하기 위한 명령어를 넣으면 끝난다.

다음으로 stage:registry 부분은 다음과 같다.

stage:registry
YAML
1
2
3
4
5
6
7
8
9
10
11
12
helm-registry:
  stage: registry
  dependencies:
    - helm-package
  before_script:
    - PACKAGE=`ls *.tgz`
  script:
    - 'curl --request POST --form "chart=@${PACKAGE}" --user gitlab-ci-token:$CI_JOB_TOKEN "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/packages/helm/api/stable/charts"'
  tags:
    - java-runner
  only:
    - main

package 를 하고 난후에 패키징된 파일의 확장자는 tgz 이다. 이것을 Shell 환경변수로 만들고 script 명령어에서 사용할 수 있다. curl 명령어중에서 –user 부분에 gitlab-ci-token 과 $CI_JOB_TOKEN 은 이미 정의된 사용자와 변수다. 이것은 Gitlab 에서 별도로 생성하지 않는다. 이미 있는 것이다. URL 에 있는 CI_API_V4_URL 과 CI_PROJECT_ID 도 이미 정의된 변수다. 알아서 맞게 파싱을 해준다.

AWS ECS, Service 생성 오류 디버깅

AWS ECS 에서 Cluster 를 생성하고 난 후에 Service 를 생성해야 한다. AWS ECS 는 Cluster, Service 생성시에 CloudFormation 으로 생성하게 되는데, 문제는 오류가 발생했을때다.

“Circuit Breaker” 라고 되어 있어서 그냥 CloudFormation 이 실행하면서 예기치못한 오류가 발생한 것으로 착각할 수 있다. 하지만, 이것이 문제가 아닐 수도 있다.

Service 생성 Event 확인

CloudFormation 에서 “CREATE_FAILED” 라고 되어 있어도 AWS ECS 에 Service 에는 service 가 생성되어 있다. Service 를 클릭하고 들어가서 Events 탭을 클릭하면 생성이 진행되었던 과정을 볼 수 있다.

여기서 task 로 시작하는 해쉬값 링크를 볼 수 있다. 이것을 클릭하고 들어가본다.

이제 뭐가 문제인지를 확실하게 보인다. “pull image mainfest has bean retried 1 time(s)” 로 되어 있고 ECR 에서 이미지를 못가지고 오고 있음을 알 수 있다.

Harbor, Helm chart 사용하기

Harbor 도 Helm Chart Repository 를 제공한다. 한가지, Harbor 최신 버전에서는 chartmuseum 이 제거 되었다. 과거 버전에서는 chartmuseum 을 플러그인으로 설치해야 Helm Chart 저장소를 사용할 수 있었지만 최신 버전에서는 Helm Chart 저장소가 내장됐다.

변화는 또 있다. Helm Chart 저장소가 OCI 타입이라는 것이다. OCI 타입이면 helm 명령어를 이용하는 방법도 다르다. 먼저, helm repo add 와 같이 repo 관련 명령어는 사용할 수 없다. 또, helm pull 에서 oci:// 를 붙여줘야 한다.

대략 다음과 같이 사용해야 한다.

Harbor 에 helm 명령어 사용하기
ZSH
1
2
3
$ helm registry login https://harbor.systemv.local/charts --ca-file /etc/docker/certs.d/harbor.systemv.local/ca.crt --username systemv --password 14321
$ helm registry push hello-helm-0.1.0.tgz https://harbor.systemv.local/charts/hello-helm:1.0.0
$ helm pull oci://harbor.systemv.local/charts/hello-helm --version 0.1.0

Gitlab, Helm 저장소 사용하기

Gitlab 은 아주 좋은 툴이다. 단순하게 git 저장소 뿐만 아니라 Container 저장소, Package 저장소를 제공한다. 여기서 Package 저장소가 Helm chart 저장소이다. 이 문서는 Gitlab 에서 Helm 저장소를 이용하는 방법에 대해서 다룬다.

Project

Gitlab 은 기본적으로 소스코드를 저장하기 위한 카테고리로 Project 를 만든다. 이렇게 하는 이유는 Gitlab 은 다양한 저장소 타입을 제공하기 때문에 딱히 Git 저장소 라고 불리기도 애매하기 때문이다. Gitlab 은 Git 명령어를 이용하지만 저장소는 Git, Container, Package, Terraform states, Terraform modules 등을 제공한다.

여기서 Helm 저장소를 Package Registry 로 부른다. 한가지 짚고 넘어가야하는 것은 Package Registry 는 소스코드를 저장하는 것이 아닌 Helm 의 Package 형태를 그대로 저장하는 것이다. Helm Package 라는 것이 Helm template 의 텍스트 파일을 압축한 형태의 결과물이고 이를 수정하기 위해서는 Helm chart 의 소스코드 형태로 가지고 있어야 한다.

Gitlab 은 텍스트 형태의 Git 저장소, Package Registry 를 하나의 프로젝트에서 관리할 수 있기 때문에 Helm Chart 를 위한 저장소 두개를 한꺼번에 운영할 수 있게 된다.

helm-employee-role 프로젝트

예를들어 설명하겠다. Gitlab 에서 helm-employee-role 이라는 프로젝트를 생성한다. 그리고 helm chart template 을 Git 코드 저장소에 저장을 한다. 이렇게 되면 다음과 같이 보인다.

Code Repository 에는 Helm Chart 의 텍스트를 저장하게 된다. 이것은 Helm Chart 의 소스코드라고 부르는 형태로 Package Registry 와는 다른 것이다.

이제 Package Registry 를 사용해 보자.

Personal Access Token

Gitlab 에는 Access Token 이 존재한다. 이는 Personal, Project, CI/CD Access Token 으로 세가지 형태가 있다. 각 Access Token 은 용도에 맞게 사용하게 되는데, 아무래도 Personal Access Token 이 권한 제약이 많다. 꼭 필요한 권한만을 가지고 있는 것이고, 보안상 최소한의 권한만을 부여한다는 방침을 따른다면 Personal Access Token 이 제일 적합하다.

Gitlab 에 로그인하고 ‘User settings -> Access Tokens’ 에서 토큰을 발행할 수 있다. 이때 스코프(Scope) 라고해서 Token 의 권한을 부여해야하는데, api 만 체크해주면 된다.

Publish a package

Gitlab 공식문서에는 Package Registry 에 Helm 을 올리는 것을 Publish 라고 표현하고 있다. 다음과 같은 방법으로 publish 한다.

curl 을 이용한 publish 하기
ZSH
1
2
3
4
5
]$ curl --request POST \
     --form 'chart=@employee-role-0.1.0.tgz' \
     --user systemv:glpat--W9yNk-99PLCrE8vrgSx \
     https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/api/stable/charts
{"message":"201 Created"}

결과가 성공적으로 생성이되었음을 알려주고 있다. 실제로 잘 되었는지를 Gitlab 웹 화면을 통해서 보면 다음과 같다.

위와 같이 나온다. 클릭해서 들어가면 다음과 같이 보인다.

아직 처음이라 별 내용은 보이지 않는다. 한가지, 저장되는 형태가 helm package 형태라는 것.

Gitlab 에 Helm 저장소 사용하기

Gitlab 의 Package Registry 에 Publish 가 되었으니 이제, 이것을 Helm 에서 사용해 봐야 한다.

helm 을 이용하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
]$ helm repo add --username systemv --password glpat--W9yNk-99PLCrE8vrgSx helm-employee-role https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/stable
"helm-employee-role" has been added to your repositories
]$ helm repo list
NAME                    URL                                                                                                            
helm-employee-role      https://gitlab.systemv.local:8001/api/v4/projects/23/packages/helm/stable
]$ helm search repo helm
NAME                                    CHART VERSION   APP VERSION     DESCRIPTION                
helm-employee-role/employee-role        0.1.0           1.16.0          A Helm chart for Kubernetes
]$ helm install employee-role helm-employee-role/employee-role --version 0.1.0
NAME: employee-role
LAST DEPLOYED: Sun Feb 18 22:32:50 2024
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
]$ helm list
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
employee-role   default         1               2024-02-18 22:32:50.463004041 +0900 KST deployed        employee-role-0.1.0     1.16.0

위와같이 helm 을 사용할때에 Gitlab 저장소를 이용할 수 있다.

여기서 한가지 더, Gitlab 의 Package Registry 는 OCI 타입의 저장소가 아니다. 최근의 Harbor 의 경우, Helm Chart 저장소는 OCI 타입을 지원한다. OCI 타입을 Helm 에서 사용할 경우에 helm repo 명령어를 사용하지 않는다.