# GithubAction

lgs03042

개발자로서 코드의 변경사항을 신속하게 라이브 환경에 반영하는 것은 중요합니다. GitHub Actions와 AWS S3를 활용하면 쉽고 빠르게 CI/CD 파이프라인을 구축할 수 있습니다. 이 포스팅에서는 그 방법을 자세히 알아보겠습니다. 1. AWS S3 버킷 생성 및 정적 사이트 호스팅 설정하기 1.1 버킷 생성하기 로그인: AWS Management Console에 로그인 S3로 이동: 서비스 목록에서 S3를 선택. 버킷 생성: '버킷 생성' 버튼을 클릭하여 이름과 리전을 설정합니다. 버킷 생성 시 '퍼블릭 엑세스 차단' 옵션을 해제합니다. (이로써 모든 사용자가 호스팅된 파일에 접근할 수 있게 됩니다.) 1.2 정적 웹 사이트 호스팅 설정 생성한 버킷을 클릭하고

9to0

개요 환경 구성 EC2 환경에서 Docker를 이용하여 백그라운드에서 자바 컨테이너를 실행할 수 있다. Pre-project 단계에서 우리는 다음과 같은 CI/CD 환경을 구성하였다. >- Github Action, workflow >- Docker >- AWS EC2 (ubuntu) Trouble 문제는 AWS EC2 환경에서 환경변수를 여러 차례 설정해보았지만, 정작 docker에서 실행하는 jar 파일에 환경변수가 전달되지 않는 문제가 발생했다. >- sudo vi /etc/environment : 환경변수 편집 프로그램 열기 (환경변수 작성) >- source /etc/environment : 환경변수 적용 >- env : 현재 설정되어 있는 환경변수 확인 env에 정상적으로 저장되어 있는 환경변수를 ec2에서 확인했음에도 불구하고 docker 컨테이너 내부에서 환경변수가 설정되지 않았기 때문에 `JWTSECRET

cozzin

이번 글에서는 CI/CD가 무엇인지, 어떤 DevOps 플랫폼이 있는지, 동작을 이해할 때 도움되는 용어들을 알아보겠습니다. 저도 1년 반 전에만 해도 CI 개념을 잘 몰랐지만 SDK 자동화 도입하면서 CircleCI, Github Action을 다룰 기회가 많았습니다. 개발팀에서 본인이 DevOps 작업을 많이 하지 않더라도 작동 원리를 알아두면 도움이 될 거라 생각합니다. 아무래도 외부 환경에 메세지를 보내거나 빌드하는 과정에서 언젠가 에러가 발생할 수 있습니다. 제 글을 통해 개념을 익혀뒀다가 필요할 때 앞장서서 문제를 해결할 수 있으면 좋겠습니다. CI가 뭐지? - Continuous Inte

ljo094822

yml 파일 분석 및 공부한것 정리 빌드와 배포할때 쓰인다. yml 파일로 인해 많은 고생을 했었다. 처음배우는 부분이라서 혼자서 찾기 힘들었지만 그 시간 만큼 좋은 공부가 되었다. React+Typescript 관련하여 빌드 및 배포에 사용한 yml 파일이다. 추가 사항으로 공부했을때 참고 한 사이트 이다. 카카오에 근무하면서 올리신것 같은데 많은 도움이 되었다. 원본 url : https://fe-developers.kakaoent.com/2022/220106-github-actions/

ddonghyeo_

Amazon EC2 Linux환경에서 진행했다. >### EC2 Docker 설치 시작하기 전에 yum 패키지를 모두 최신 버전으로 업데이트 해주었다. yum을 이용해서 docker를 설치했다. Docker 버전 확인 Docker 시작 <br

thdcodud01

movie > GitHub Actions란? GitHub Actions는 코드 저장소(repository)로 유명한 깃허브(GitHub)에서 제공하는 CI(Continuous Integration, 지속 통합)와 CD(Continuous Deployment, 지속 배포)를 위한 비교적 최근에 추가된 서비스입니다. GitHub Actions를 사용하면 자동으로 코드 저장소에서 어떤 이벤트(event)가 발생했을 때 특정 작업이 일어나게 하거나 주기적으로 어떤 작업들을 반복해서 실행시킬 수도 있습니다. 예를 들어, 누군가가 코드 저장소에 Pull Request를 생성하게 되면 GitHub Actions를 통해 해당 코드 변경분에 문제가 없는지 각종 검사를 진행할 수 있고요. 어떤 새로운 코드가 기본 브랜치(master 또는 main

shleecloud

들어가며 어느날 잘 동작하던 배포 과정이 깨졌다. 당장 배포해야 되는 내용이 있어서 급하게 조치해야 했다. 그 과정에서 찬찬히 살펴보지 못하고 바보같은 실수를 해서 이렇게 남긴다. 증상 Github Action 과정에서 elastic 관련 버전 이슈가 발생했다. 기존에 쓰던 버전이 오래되어 의존성 걸린 패키지가 관리되지 않는 경고메시지가 나오긴 했는데 갑자기 이렇게 실패하는건 이상했다. 해결 컨테이너를 만들 때 yarn.lock 파일을 포함하여 설치하게 수정했다. 과정 처음엔 Github Action만 보았다. (지금 보니 에러메시지에 답이 있었다) 설치 과정을 살펴보던 중 Github Action에서 패키지 설치가 진행되지 않는 사실을 깨달았다. 패키지 설치는 ECS 컨테이너를 만드는 액션에서 설치를 진행하는데, package*.json 파일만 복사하고 yarn.lock 파일을 복사하지 않았다. DockerFil

jt_include_rw

들어가며 > - Next.js을 Elastic Beanstalk Node.js 환경에 Github Action을 통해 자동 배포해요! > - yarn berry의 PnP zero-install을 적용한 Next.js 어플리케이션을 배포해요! 왜 자동배포를 하였는가? 사내 QA를 위해 stage 서버에서 어플리케이션을 배포하는 상황에서 매 번 수정 ➡️ 배포 하는 과정을 자동화하여 생산성을 향상 시키고 싶었어요. ➡️ release/* branch에 commit이 push되면 stage 서버 자동 배포 production 배포 시에도 QA가 완료된 버전을 github branch merge를 통해 자동 배포하여 생산성을 향상 시키고 싶었어요. ➡️ main branch에 commit이 push되면 production 서버 자동 배포 ❗️아래 글은 stage 서버 자동 배포에 관한 github action입니다. 구현 branch 배

marigold1

프로젝트의 배포를 위해 github action을 이용하여 무중단 배포를 하게되었다 오류발견 처음에는 백엔드쪽 서버 배포를 위해 다음과 같이 gradle.yml를 작성했다. > 환경변수 설정을위해 위와 같이 yml file이 어디있는 지 path를 지정해주고, github secret 을 이용해 key설정을 해주었다. 액션결과 성공적으로 S3에 올라간 것을 확인할 수 있었고 codedeploy를 이용한 배포까지 잘되었다. 우리는 s3의 정적 호스팅을 이용한 배포였기 때문에 결국엔 s3의 엔드포인트에서 웹페이지 접속이 되어야 했다. 무슨 이유인지 s3를 통한 접속 시 아래와 같은 페이지를 볼 수 있었다. ![](https://velog.velcdn.com/images/marig

juyoung810

현재 상황 Dockerfile 을 통해 작성한 application 을 image 로 만들 수 있도록 정의 Github Action Worklfow 를 통해 특정한 trigger 가 발생할 경우 자동으로 작성한 Dockerfile 를 기반으로 이미지를 생성해 image registry 에 push k8s deployment manifest 를 통해 image registry 에서 이미지를 가져와 Deployment 를 생성한다. → 이제 생성한 Deployment 를 k8s 환경에 띄우면 애플리케이션이 실행된다. > 💡 ArgoCD 는 helm 으로 감싸진 application 뿐만 아니라 그냥 manifest 도 배포가능하다.

disdos0928

소나코드 서버의 최소 요구사항이 상당히 높아 프리티어로는 구축이 힘들수 있습니다 😭😭😭 > 개요 제가 이전 글에서 병합을 하기전 를 통해 빌드를 테스트 하는 것 가지는 생각했습니다. 하지만 이 때 불현듯 예전에 봤던 아티클이 생각 났습니다.(효과적인 코드 리뷰를 위해) 본문의 내용중 일부 발췌 지금 제가 F-Lab에서 진행중인 프로젝트는 저와 다른 멘티 한명 , 멘토님 총 3명이 진행중인

disdos0928

이 글을 적게 된 이유 프로젝트의 설계가 시작된 후 다음으로 진행한 일이 CICD의 구축 과정을 진행했습니다. 이 글에서는 CI를 하면서 어떤 일을 더 할 수 있었고, 왜 했는지에 대해 글을 써보려 합니다. CI ( Continuous Integration ) | 지속적인 통합 > 지속적인 통합이라고 불리는 CI는 말 그대로 서로 다른 작업을 하는 개발자들의 코드를 > 하나로 병합하는 과정을 의미합니다. 서로의 코드가 합쳐지는 매우 당연한 일입니다. 하지만 그 과정에서 일어나는 문제들은 당연한 문제들이 아닙니다. 회사에서 있었던 일로 GitLab 을 이용해 버전 관리를 하던 도중 어떤 개발자가 자체적인 테스트를 하지 않고 빌드 자체가 안되는 코드의 상태로 운영 서버에

jhyoo9727

[Github Action] AWS IAM Role로 접근 Github Action을 사용하면 빌드, 테스트, 배포 및 다른 작업을 실행할 수 있습니다. 하지만 AWS 리소스를 사용하려면 AWS 자격 증명 정보가 필요합니다. 일반적으로 이는 AWS Access Key ID와 AWS Secret Access Key로 구성됩니다. 그러나 Github Action에서는 보안상의 이유로 Access Key를 사용하는 방식은 권장되지 않습니다. 대신 IAM Role로 인증하여 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있습니다. IAM Role은 AWS 리소스에 대한 액세스 권한을 가지고 있는 역할(Role)입니다. IAM Role을 사용하면 Access Key ID와 Secret Access Key를 사용하여 AWS 리소스에 대한 액세스를 직접 제어할 필요가 없습니다. 따라서 Github Action에서 IAM Role로 인증하는 방법에 대해 알아보겠습니다. Identi

boost_dev

0. 설정 fastapi requirements.txt에 추가 main.py에 handler = Mangum(app) 추가 0.1 DB 데이터 베이스 수정에서 db 파라미터를 사용중인 db로 변경 db가 제대로 들어갔는지는 하이디로 확인 하이디의 ip는 db의 연결 보안에 있는 엔드포인트 fastapi의 db도 host는 AWS의 엔드포인트 > 이제 docker/mysql 내부의 코드들은 발생x, docker/api만 발생 1. 진행 순서 > RDS -> IAM -> S3 RDS는 db에 들어가는 애 s3는 화면을 보여주는 애 1.1 RDS 1.1.1 RDS 작성

9bin08

배포 자동화를 도입한 이유는 3가지이다. 효율성 : 배포를 위한 매번 같은 프로세스를 줄이자 일관성: 프로젝트를 누가 변경했는지에 관계없이 모든 코드 변경이 동일한 방식으로 테스트되고 배포되도록 하자. 이는 최종 빌드에서 휴먼에러 및 환경변수의 리스크를 줄여줌. 정확성 : 프로젝트는 여러 환경 변수에 의해 다양한 버전으로 운용한다(prod/dev/test)이 때, 자동화가 안되어있는 프로젝트에서 배포 하기 전 환경 변수설정을 깜빡하여 빌드를 다시 시도해본 경험이 있다면 무조건 도입을 추천한다. 1. AWS IAM KEY AWS환경을 이용하기 위해 KEY가 필요하다. IAM에서 accesskey, secret access key 발급 먼저 하자. 2. 레포지토리 secrets

juyoung810

Application Repository 에 새로운 push 가 발생하면 작성한 Dockerfile 을 이용해 새로운 Image 를 build 하고 Github image Registry 에 생성한 image 를 올린다. Container Registry(github image registry) 란 > 생성한 image 를 github organization 혹은 personal account 내에 저장시켜, repository 에서 image 에 접근할 수 있도록 한다. Image 를 생성한 후 저장,공유하고 생성될 경우 접근할 수 있는 곳이 필요하다. local 에서 image 를 생성한 후 image registry 에 push 하고, 그것을 k8s 환경에서 registry 를 통해 받아올 수 있다. 따라서 image registry 는 CI/CD workflow 에서 중요한 역할을 한다. repository 의 접근 허용 범위를 그대로 따르게 할수

kws60000

github action ? jenkins 와 더불어 CI/CD 구축을 위해 사용됩니다. github 에서 가상환경을 제공해줍니다. 장점 CI 를 위한 추가 서버가 필요 없다는 게 큰 장점이었습니다. git hook 에 따라 배포를 실행할 수 있습니다. 단점 유료 계정이 아니라서 그런지 몰라도 빌드 시간이 오래걸렸습니다. jenkins 로 배포할 때 총 20초 정도 걸렸었는데, 2분 정도 소요됐습니다. (s3 업로드 까지) 시작하기 과정을 간단하게 요약한 글입니다 보다 상세한 내용은 해당 글을 보시는걸 추천드립니다. https://blog.bespinglobal.com/post/github-action-%EC%9C%BC%EB%A1%9C-ec2-%EC%97%90-%EB%B0%B0%ED%8F%AC%ED%95%98%EA%B8%B0/ 1. IAM 사용자 추가 github 코드를 s3 로 업로드하기 위해 인증된 사용자라는 검증

dongdorrong

Github Action 테스트의 경우 간단하게 Docker 이미지를 만들어서 workflow를 작성하는 것에 대해 테스트를 진행하였다. 1. Dockerfile 작성 2. GitHub Container Registry로 이미지 푸시 GitHub Container Registry에 접근하기 위해서는 액세스 토큰이 필요하다. https://github.com/settings/tokens 에서 토큰을 만들 수 있고, 해당 토큰을 임의 파일에 삽입하고 명령을 수행하면 이미지를 푸시할 수 있다. 3. workflow 작성 master 브랜치에 적용하면 바로 작동할 수 있도록 조건을 상단에 적용하였다. workflow 작성하고 merge 했을 때 상태를 확인해보자. 변경된 태그

juyoung810

Github Actions 란 > 💡 Github actions 란 build,test,deployment pipeline 을 자동화해주는 CI/CD 플랫폼이다. repository 의 모든 PR 를 test,build 하고 production 환경에 PR 를 merge 하는 workflow 를 생성할 수 있다. repository 에서 events 가 발생할 경우 workflow 를 실행할 수 있는것이 기존 DevOps 와의 차이점이다. ex) repository 에 누군가 새 issue 를 만들때, 자동으로 적절한 label 을 설정하는 workflow 를 실행할 수 있다. Github Actions 의 구성요소 ![](https://docs.git

gn0lee

자동화를 개선한 이유 버전관리 이전 자동화에서는 새로 배포시 무조건 patch 명령어를 사용했다. 당시 자동화 코드를 작성할 때 patch가 정확히 무엇인지 모르고 사용했다. 버전이 동일하면 npm publish 실행시 에러를 발생해서 자동으로 버전을 높여주는 코드를 찾아서 사용한 것이었다. 문제는 여기서 시작되었다. 디자인 시스템 코드가 완전히 바뀌어서 디자인 시스템을 사용하는 프로젝트에서 코드를 수정해야 하는 경우가 있었다. 하지만 사용자가 이를 인지하지 못하면 자동으로 버전이 업데이트 되어 빌드시 에러가 발생하였다. 자동 commit & push 현재 자동화 시스템에서 github bot이 버전 변경이나 library 폴더의 변경사항을 자동으로 github에 반영한다. 스테이징, 커밋, 푸시 순으로 진행한다. 보통의 경우 github에 변경사항을 반영할때 해당 브랜치가 최신 상태이어야 한다. 그런데 github action이 진행 중 일때 누군가가 브랜치를 변