가장 긴 단어가 2개 이상이면 첫번째로 등장하는 단어GitHub Action을 이용하여 CI 상에서 Mini node server를 Docker 이미지로 만든 후, 여러분의 Docker Hub에 push하세요
1. CI 상에서 주어진 Dockerfile을 이용해 Docker 이미지를 빌드할 수 있도록, workflow를 새로 만드세요.
- 다음 레퍼런스를 참고해서 Docker 빌드용 GitHub Action workflow를 만드세요.
- workflow를 추가한다고 해서 GitHub Action이 즉시 작동하지는 않을 것입니다.
- repository에서 오른쪽 사이드바를 살펴보면, Release -> Create a new release 링크가 존재합니다. - 이 링크를 누르고 새로운 릴리스를 발행합니다. 설정은 다음과 같이 진행합니다.
- Choose a tag: v1.0.0
- Release title 및 Release notes는 여러분이 자유롭게 입력하세요.
- Publish release 후에 GitHub Action이 작동하나요?
Q. 왜 작동이 되는 걸까요? 아까는 왜 안 됐을까요?
2. 인증 정보에 대한 환경 변수를 만드세요.
- 1번 과정을 통해 GitHub Action을 실행하면 그 결과는 실패로 나타날 것입니다. 무엇이 잘못되었는지 먼저 로그를 살펴보세요.
Q. 왜 실패했을까요? 로그에서 그 이유를 찾아보세요.
- Workflow YAML 파일을 자세히 살펴보면, DOCKER_USERNAME 및 DOCKER_PASSWORD라는 환경 변수가 존재합니다. 말 그대로 아이디와 비밀번호와 같은 민감정보를 YAML 코드에 입력해서 git commit 기록으로 남겨둔다면, 더 이상은 그 비밀번호를 사용할 수 없게 될 것입니다. (돌이킬 수 없어요!)
GitHub에서는 이러한 환경 변수를 안전하게 보관할 수 있는 기능을 제공합니다. Settings -> Secrets에서 환경 변수를 설정하세요.
3. Dockerfile 빌드 결과를 확인하고, Docker Hub에 이미지가 제대로 push 되었는지 확인하세요.
앞서 이 과정을 다 잘 따라왔다면, 여러분 각 개인의 Docker Hub에는 mini-node-server 이미지가 성공적으로 push되어 있을 겁니다.
1. Github에 새로운 workflow 생성합니다.
2. Dockerfile 자동 빌드 할 수 있는 docker yaml 파일 작성 합니다. 작성 후 git push 해서 업로드 하거나 github actions 에서 새로 생성 가능합니다.
3. Yaml 파일 업데이트 하면 빌드 진행이 안되어 github에서 Release 설정 해야합니다.
Github -> release -> Create a new release -> tag V1.0.0 설정
4. Release 설정 하면 Workflow가 분리 되고 업로드된 YAML 파일 기준으로 자동 빌드 하지만 log in error 가 뜹니다. 그 이유는 YAML 파일에 secret DOCKER USER / PASSWORD 를 github에서 설정 안 해서 그렀습니다.
Github에서 SECRET 설정 헐려면
- Settings -> Secrets and variables -> actions -> new repository Secret
- Secrets에 Docker username + password 기입
5. Secrets 설정 완료 하면 log in은 완료 하지만 다른 error 가 뜹니다.
- error 가 뜨는 이유는 YAML 파일에서 images 저장소가 다르기 / 없기 때문입니다.
6. 브라우저 Docker Hub에 들어가서 create repository 해서 새로운 repository 생성 하면 하단 이미지처럼 나옵니다.
7. Github에 있는 YAML 파일 images 부분에 docker hub에 생성한 정보들을 업데이트 해야합니다.
8. YAML 파일 업데이트 후 workflow re-run 할 경우 이상없이 잘 작동 될 예정입니다.
9. 작동이 되면 docker hub에 image 파일들이 생성 됩니다. Dockerhub repository 폴더에서 확인 할 수 있습니다.
10. Docker Image가 잘 실행 되는지 확인 위해 docker pull jackydevops/dobdockerimage:V1.0.0 하여 image를 받고 docker run -p 4000:4000 jackydevops/dobdockerimage:V1.0.0 포트 4000으로 실행 합니다.
주의 할 점 :
1. YAML 파일 업데이트 할 경우 정확한 branch / tag에 push 해야합니다. 잘 못 할 경우 workflow file 이 업데이트 되지 않아 문제가 해결 안될 수 있습니다.
2. Docker hub repository 가 있는지 확인 하고 폴더 명이 Yaml 파일 하고 일치하는 확인
3. Github Secrets 설정 및 variable이 맞는지 다시 확인
4. 지속적으로 업데이트나 새로운 workflow 할 경우 github release 업데이트
왜 Release 사용 하나?
GitHub에서 릴리스는 프로젝트의 소프트웨어나 코드의 특정 버전을 패키지화하고 배포하는 데 사용됩니다. 릴리스를 생성함으로써, 개발자는 변경 사항의 세트를 버전화된 패키지로 묶어 소프트웨어를 다운로드하고 사용하거나 배포할 수 있습니다.
릴리스는 여러 가지 워크플로우에서 유용합니다.
첫째로, 릴리스를 생성함으로써 개발자는 코드베이스의 변경 사항을 구조적이고 조직적인 방식으로 관리할 수 있습니다. 릴리스를 생성함으로써, 개발자는 특정 버전이나 마일스톤에 관련된 변경 사항과 기능을 그룹화하여 소프트웨어를 업데이트하고 관리하기 쉬워집니다.
둘째로, 릴리스는 소프트웨어를 고객이나 다른 개발자와 같은 최종 사용자에게 배포하는 데 사용될 수 있습니다. 릴리스를 다운로드할 수 있게 함으로써, 사용자는 개발자가 검증하고 테스트한 특정 버전의 소프트웨어에 액세스할 수 있습니다.
마지막으로, 릴리스는 다른 개발자나 기여자들과 협업하는 데 사용될 수 있습니다. 릴리스를 생성함으로써, 개발자는 다른 사람들과 특정 버전의 코드베이스를 공유하여 제어된 구조적인 방식으로 변경 사항을 기여하거나 버그를 수정할 수 있게 됩니다.
요약하면, 릴리스는 변경 사항을 관리하고 소프트웨어를 배포하며 다른 사람들과 협업하는 데 사용되는 GitHub에서 강력한 도구입니다. 따라서 많은 개발 워크플로우에서 필수적인 역할을 합니다.
'지속적 통합' 카테고리의 다른 글
| DevOps Day 34 (4.21) 지속적 통합_릴리스 준비 (0) | 2023.04.21 |
|---|---|
| DevOps Day 33 (4.20) 빌드 및 테스트 자동화 Sprint “Github Action을 이용한 빌드 및 테스트 자동화” (0) | 2023.04.21 |
| DevOps Day 33 (4.20) 지속적 통합_테스트 (0) | 2023.04.20 |
| DevOps Day 33 (4.20) 지속적 통합 (0) | 2023.04.20 |
| DevOps Day 33 (4.20) 지속적 통합_CI/CD 리뷰 (0) | 2023.04.20 |
