'Git'에 해당하는 글 17건

CodeBuild / CodePipeline

Server/AWS 2021. 12. 18. 00:09

aws-eks-ci-cd

 

EKS 에서의 CI / CD 를 고민중이다. AWS 리소스만을 이용하는 방법, 범용적인 CI/CD 를 사용하는 방법... ArgoCD, TerraForm, Jenkins 등 뭐가 많지만 되도록 AWS 리소스를 사용해 보기로 했다. 예전에 ECS 배포할 때는 gradle 에서 Docker 이미지 생성 / ECR 업로드 / 배포까지... 전부 해결했었다. 로컬에서 태스크만 실행하면 되니 build.gradle 만 기다랗게 작성하는 것 빼고는 별 문제가 없었다. 그 때의 애로사항은 배포하려는 개발자의 PC 에 Docker 가 실행되고 있어야 한다는 점. ECR 인증키가 git 에 포함된다는 점. 배포시 오류가 발생한다면 즉시 파악이 어려운 점... 트집을 잡자면 그 정도. 하지만 대부분의 개발자가 docker 를 사용하고, git 도 프라이빗, 배포시 오류는 알림으로 처리했었고... 라며 흡족하게는 썼었지만, 이번엔 왠지 도구를 이용해야만 할 것 같은 느낌적인 느낌. 시간 있으면 이것저것 다 써보는게 좋은거지. 싶어서 CodeCommit, CodeBuild, CodePipeline 을 사용해 보았다.

 

 

사용할 AWS CI/CD Resource

 

  • CodeCommit
    - git 저장소 / 소스 위치
  • CodeBuild
    - 소스코드를 가져와 Test/Build 실행.
    - 자체 컴퓨팅으로 docker 이미지 생성, ECR 이미지 업로드, EKS 배포에 관한 빌드사양 파일 작성(buildspec.yml)
  • CodePipeline
    - git 저장소에 소스코드 변경이 감지되었을 때, source 아티팩트 S3 업로드 후 CodeBuild 실행

 

 

CodeBuild 생성

 

AWS 관리콘솔에서 빌드 프로젝트 만들기

  • 관리형 이미지 컴퓨팅 선택
  • 역할 이름 : 여러 빌드 프로젝트를 관리한다면 하나로 재사용
  • 권한이 있음(privileged) : 도커 이미지를 빌드하거나 빌드의 권한을 승격시 필요
  • VPC / 컴퓨터 유형 선택 : 빌드 성능 결정
  • 환경 변수 : buildspec 에 노출하고 싶지 않은 키/값 지정
  • Buildspec 이름 : 실제 buildspec 파일의 경로 지정
  • 캐시 유형 : 로컬 (DockerLayerCache, SourceCache, CustomCache)
  • 나머지 기본값

 

 

buildspec.yml 파일 작성

 

빌드 프로젝트 생성시 설정한 경로에서 buildspec.yml 를 작성한다. 기본적으로 4개의 페이즈가 있다.

  • install : 빌드 환경 구성
  • pre_build : 빌드에 필요한 ECR 로그인이나 패키지 종속성 설치 등
  • build : 빌드 실행
  • post_build : 빌드 결과물 처리, ECR 이미지 푸시, 빌드 알림 등

 

페이즈 마다의 규칙이 있지는 않지만, 추후 구간별 처리 속도를 알 수 있으므로 구분하여 사용자 정의.

 

$ vi buildspec.yml

version: 0.2

phases:
  install:
    runtime-versions:
      java: corretto11
    commands:
      - curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
      - chmod +x ./kubectl
      - mv ./kubectl /usr/local/bin/kubectl
      - aws --version
      - aws eks update-kubeconfig --region ap-northeast-2 --name example-cluster
      - kubectl get po -n exapi
  pre_build:
    commands:
      - echo pre_build Logging in to Amazon ECR...
      - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include-email)
      - REPOSITORY_URI=${REPO_ECR}
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
  build:
    commands:
      - echo Build started on `date`
      - gradle --version
      - chmod +x gradlew
      - ./gradlew :ApiFacility:build
      - docker build -t $REPOSITORY_URI:latest ./Api
      - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker images...
      - docker push -a $REPOSITORY_URI
      #- kubectl apply -f ./AWS/example-deployment.yaml
      - kubectl rollout restart -f ./AWS/example-deployment.yaml

 

위에 정의한 사양은,

  • install : 자바환경, kubectl 설치, kubeconfig 구성
  • pre_build : ECR 로그인, ECR 경로, 이미지 태그명 정의
  • build : gradle 빌드, docker 이미지 생성
  • post_build : ECR 이미지 푸시, eks deployment 롤링 업데이트

 

또한, 위 사양처럼 REPO_ECR 등의 프라이빗 정보들은 빌드 프로젝트 구성시 환경변수로 지정한 변수명으로 사용할 수 도 있다. echo 나 이미지 태깅 관리 때문에 조금 길어지긴 했는데 필요에 맞게 사용자 정의...

 

 

CodePipeline 생성

 

AWS 관리콘솔에서 파이프라인 생성

  • 역할 이름 : 여러 파이프라인을 관리한다면 하나로 재사용
  • 아티팩트가 업로드 될 버킷 위치 수동 지정시
  • 소스 스테이지 : CloudWatch 로 변경 감지, 출력 아티팩트 형식은 기본값을 사용하여 zip 형식의 데이터를 사용해도 무방하지만 간단히 메타데이터만 전달하는 전체 복제 선택.(gitpull 권한 추가 필요)
  • 빌드 스테이지 추가 후 배포 스테이지 건너뛰기

 

 

배포 테스트

 

CodePipeline 이 생성되면 즉시 실행이 되는데, 아니면 수동으로 빌드하던지, git 소스를 푸시하던지... 해서 배포 롤링 업데이트 확인까지. 이제부터는 에러의 향연이다. CodeBuild 의 플로우를 보면 거의 모든 단계에 해당 리소스에 대한 권한이 필요하므로 생성한/된 codebuildrole 에 각 권한을 추가해 주면 된다. 

 

[에러 모음 링크]

 

마치 일부러 에러를 찾아내려는 듯한 치밀한 실수들이 많았다; awscli 버전이 1.2 라 추후 문제가 있을수도 있지 않을까 하는 걱정도 되고... CodeCommit, CodeBuild, CodePipeline, ECR, EKS 등 AWS 리소스 만으로 CI/CD 를 구성해 본 느낌은... 그냥 그렇다.ㅋ 뭔가 자동화 스러우면서도, 관리 포인트가 점점 늘어나는 찝찝한 느낌... 남은건 구성 완료에 대한 약간의 성취감? ㅋ


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Intellij upgrade

Daily/Prog 2019. 8. 27. 21:45

업그레이드 한지 1년 정도된 회사 컴퓨터. 요녀석은 온 첫날부터 블루스크린 기술을 보였었다. 1달에 한번 나타났던 블루스크린이 최근에는 하루에 5번도 나타나 나를 괴롭혔다. 나이가 들며 인내심이 강해진 나는 컴퓨터가 이 지경이 될때까지 참고 또 참았는데 프로젝트 하나가 살짝 끝난 시점에 결국 포맷을 결심했다. 블루스크린을 참았던 것도 각종 프로그램 재설치/재설정 하는게 구찮아서 였는데... 그렇게 해서 거의 1년만에 프로그램들도 버전 업그레이드를 했는데... intellij 가 문제가 됐다.




처음엔  .gitignore  파일이 문제였다. 일단 뭔가 문제가 생긴듯한 저 이상한 아이콘... 인식이 안됐는줄 알고 여기서 2시간 정도 뻘짓. 실제로 새로 pull 받은 파일들임에도 불구하고 git 에 untracked file 들이 수두룩하게 떴음. git 신버전 깔았다가 구버전도 깔았다가, git 이랑 gitignore 플러그인에서 해결될 만한것도 설치해보고 지우고... 하지만 나중에 보니 저 아이콘은 단지 .gitignore 의 새로운... 아이콘일 뿐이고, 문법이 엄격해졌는지 몇개의 상위 디렉토리가 통과된 바람에 untracked file 이 나타난 것이었다. 명확하지 않았던 정규화 사용이 문제... 문법 재조정으로 해결.




또하나. 4시간짜리 뻘짓. gradle 창에 모듈별 task 가 안나오는 또 하나의 어이없는 상황. 이전 버전 intellij 에서 잘나오던게 갑자기 안나오니 참... gradle 설정을 싹다 뒤졌다. gradle 버전별로 깔아보고 쌩쑈를 다했는데 결국엔 intellij 에서 gradle 의 project-level setting 이 사라져버린 것. 저  using explicit module groups  옵션을 선택하지 못하는 바람에 생겨버린 요상한 상황. 결국 .(dot) 으로 구분된 모듈명에서 dot 을 없애버렸다.ㅋㅋ 모듈명에 dot 을 붙인 분도 좀 그렇지만 이렇게 연락도 없이 옵션을 막 빼버리는건 너무한거 아니오?! 갈수록 새 제품 쓰는게 짜증난다. 설정하고 세팅하고 이런데다가 시간 허비하는거 이제 제발 그만~~~~





WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

4년만인가 최신 컴퓨터를 받은게. i7 8세대 3.2GHz 에 32기가 메모리... 오마오마하당. 문제는 이게 아니구...

4명이 나란히 앉아서 Windows 10 을 설치하고 git(tfs) 을 연동하는데 1명은 잘되고 나머지는 다 인증 실패


$ git clone https://tfs.blahblah.com:444/git/project1

fatal: Authentication failed for https://tfs.blahblah.com:444/git/project1


"바보들 당연히 git config 에 user 정보 넣어야지." 라고 말했지만, 결과는 같았다. 

"--global 옵션도 줘야돼." 라고 말했지만, 결과는 같았다. 끼윰~

아이디랑 패스워드를 입력했는데 인증에 실패했다니... URL 에 강제로 박아봐도 실패! 실패!! 실패!!!

방화벽 때매 URL 에 접속이 안되나 했더니 브라우저로는 인증이 잘만 된다. ㅡㅡ;;

구글로부터 찾은 해결 방법은...


[제어판] - [사용자 계정] - [자격 증명 관리자] - [Windows 자격 증명] - [일반 자격 증명 추가]

git:https://tfs.blahblah.com:444


이렇게 URL 앞에 git 만 붙여주니 해결되었다.



어떤 식으로든 클라이언트에서 저와 같은 URL 접속시에 패스워드를 전달 못하는 문제인거 같은데 Windows 10 에 뭔 보안이 또 강화됐나.

의문스러운건 다 같은 버전의 Windows 랑 git 을 깔았는데 자격 증명 설정 없이 된 사람은 뭐냐고...

또 Windows 10 을 사용하는 모든 사람들이 이 문제를 직면하진 않는다는거... 왓 더 ㅍ!!!




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

CodeStar

Server/AWS 2018. 9. 17. 21:31

특정 프로그래밍 언어로 개발/빌드/배포 환경을 미리 구성된 템플릿을 사용하여 빠르게 구축해 주는 서비스이다. 예를 들어, Laravel 로 PHP 개발을 하려 한다면, EC2 / Git / CodeBuild / CodeDeploy / CodePipeline 등을 미리 구성해 주며 git 에 push 만 하면 자동 배포되어 결과를 확인할 수 있다. 그리고 제공되는 대시보드에서 프로젝트의 개발/빌드/배포 등의 이벤트 현황을 즉시 확인할 수 있다. 아무래도 미리 준비된 템플릿으로 빠르게 구성되는 장점은 있지만, 언어나 프레임워크의 버전, 서버종류 등의 선택이 제한적인 단점 때문에 사용할 일이 있을지는 모르겠다.





CodeStar 는...


CodeStar 는 AWS 를 기반으로 애플리케이션을 빠르게 개발, 빌드, 배포할 수 있는 클라우드 기반 서비스이다. CodeStar 프로젝트를 생성하면 이미 만들어진 CloudFormation 템플릿 중 원하는 환경의 어플리케이션을 선택할 수 있다. 사용되는 Service 들이 모두 리전 별 서비스이므로 CodeStar 역시 리전 별로 서비스한다. CodeStar 자체는 무료이므로 함께 사용하는 리소스의 요금만 발생된다.



CloudFormation 템플릿 선택사항


  • Application : Web application / Web service / Static Website / AWS Config Rule
  • Service : Elastic Beanstalk / EC2 / AWS Lambda
  • Language : Python / PHP / C# / Node.js / Ruby / Java / Go / HTML


Web application 와 Web service 의 차이라면 Web application 은 UI 나 웹페이지 기능이 많고, Web service 는 RESTful 같은 API 기능에 특화되어 있는 것 같다. 그 외에도 빌드가 트리거 될 AWS CodeCommit 나 GitHub 중 하나의 저장소를 선택해야 하고, 리소스 구성 세부 정보에서 배포될 EC2 와 VPC, Subnet 등을 설정할 수 있다.


CodeStar 에는 프로젝트, 도구 체인 및 중요 이벤트를 전체적으로 보여주는 대시보드를 제공한다. 최신 프로젝트 활동 모니터링, 코드 변경, 빌드 결과 및 배포 상태 추적 같은 작업을 타일에 추가/제거하여 대시보드를 구성할 수 있다. 프로젝트를 생성하면 팀의 소유자로 추가되며, 다른 사용자를 더 추가하고 역할을 부여하여 함께 운용할 수 있다. GitHub 리포지토리나 Atlassian JIRA 같은 AWS 외부의 리소스를 사용하는 경우, 사용자 이름 및 이메일 주소를 가진 별도의 사용자 프로필을 사용할 수 있다. 코드를 변경하고 저장소에 푸시하면, Continuous deployment 타일에 진행 중인 작업이 표시되며, CodePipeline 에서 저장소의 변경 사항으로 빌드 및 배포되어 엔드포인트에서 결과를 확인할 수 있다.


프로젝트를 삭제하면 관련 내부 리소스는 자동으로 모두 삭제된다.




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Jenkins git rollback

Tool/Jenkins 2017. 2. 17. 00:34

Jenkins 에서 예전 빌드로 배포하는 방법을 좀 찾아봤다. 흔히 말하는 롤백.

배포되지 말아야 할 소스가 배포되었다거나, 잠시 이벤트성 수정이 들어갔다거나 할 경우 꼭 필요한 기능!

빌드 리스트 세부 메뉴에 Re-Build Now 라는 메뉴가 하나 더 있어서 그 당시 리비전으로 빌드/배포되면 차암~ 좋을거 같았는데... 없네...

Jenkins 에는 알아서 롤백해주는 머 그런건 아직 없는 듯...


하지만 수고+1 정도를 추가하면 가능하긴 하다. 바로 [SCM] - [Branch Specifier] 항목을 이용하면 된다.

Branch 를 지정할 경우 해당 Branch 의 최신 리비전을 가져오지만,

Tag 로 지정할 경우 해당 Tag 의 리비전을 가져오니, 롤백이 가능하다는 말쌈.


그리고 Git Tag Message 플러그인을 설치하면 슬랙 알림에 tag 메시지도 전할 수가 있다.

설치하고 [SCM] - [AdditionalBehaviours] - [Export git tag and message as environment variables] 를 선택하면 $GIT_TAG_MESSAGE 를 사용할 수 있다.



ps.

[SCM] 의 Tag 말고도 해당 프로젝트의 Build History 에서 임의로 Tag 를 달아 위 방식처럼 해당 리비전을 가져올 수도 있다.

[SCM] - [AdditionalBehaviours] - [Create a tag for every build] 에서 매 빌드마다 태그를 자동 생성할 수도 있다.

하지만 프로젝트가 여러개일 경우 복잡하고 번거로울 것 같다.

Git 에서 Tag 달아주는게 제일 무난할 듯!




WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret