CI CD (5) 썸네일형 리스트형 [Jenkins] Jenkins에서 generic webhook trigger plugin으로 webhook 이용하기 이 글은 젠킨스에서 github으로 부터 전달되는 payload를 받아서 사용하고 싶은데 괜찮은 플러그인이 없을까 해서 찾아보다가 알게된 방법을 적고 있다. 시작하기 전에 젠킨스가 외부(즉 깃헙)에서 접근이 되어야 하기 때문에 외부 도메인이 필요한데, 나는 집에서 젠킨스를 도커로 띄우고 있어 외부 도메인이 없었다. 나같이 테스트 환경에서 테스트하고 싶은 사람들은 "ngrok"을 통해서 외부 도메인을 연결해주면 된다. Ngrok 설치 및 실행 (젠킨스 외부 도메인 오픈) 1. mac인 경우 brew로 설치 brew install --cask ngrok 2. 8080포트를 ngrok 도메인에 연결 나는 현재 젠킨스를 8080으로 포트포워딩 해서 사용중이라 8080포트로 연결했다. ngrok http 8080.. [ArgoCD] argocd v.2.8이상 사이드카로 Vault Plugin 적용하기 개요 argo CD Vault Plugin은 민감한 secret들을 custom resource 또는 operator에 의존하지 않고 볼트에 저장하여 사용하는 방법이다. k8s의 secret뿐만 아니라 configmap, deployment또는 다른 쿠버네티스 리소스에서 사용할 수 있다. 사용법은 배포할 쿠버네티스 매니페스트 파일에 이런식으로 vault secret path와 key값을 넣어서 사용한다. 사용법보다는 설치방법이 조금 복잡하다. ArgoCD는 아래 두가지 방법의 설치를 제안한다. 1. argocd-cm configmap을 이용한 설치방법 2. 사이드카 컨테이너에서 설치를 진행하는 방법 나는 v.2.4.0이후에 설치하는 사이드카를 이용한 방식으로 설치를 진행했다. 그리고 글을 작성하는 시점 .. [Jenkins] Jenkins에서 sonarQube 추가하기 Jenkins란 소스코드를 지속적으로 통합하여 빌드하고 배포까지 가능하게 하는 도구이다. 오픈소스로 많은 회사에서 CI/CD tool로써 사용하고 있고, CD까지 가능하지만 쿠버네티스를 사용하는 곳에서는 CD도구인 Argocd CD와 결합하여 사용하기도 한다. SonarQube란 소스코드의 품질을 높이기 위해서 버그, 코드스멜, 취약점 분석등을 수행할 수 있는 정적 분석 도구이다. 이또한 오픈소스이고 돈주고 사용할 수도 있다. 그러면 젠킨스랑 소나큐브랑 뭔 상관이야? 라고 한다면 젠킨스는 코드를 지속적으로 통합하여 빌드 및 배포를 해주는 도구라고 했는데, 빌드에서 성공했고, 테스트 코드가 통과했다고 해서 배포해도 되는 코드일까? 혹시 보안적으로 취약한 코드는 아닐까? 그래서 젠킨스에서 빌드한 코드를 소나.. [argocd] application이 삭제되어도 kubernetes 리소스 유지하기 작년에 staging 배포를 argo로 전환한 후 여러가지 이슈를 해결하고(바쁘기도 했고) 최근에 드디어 상용쪽도 전환하였다. 👏👏 저번글에서 몇가지 이슈사항 및 주의할점을 적었는데, 중요한 한가지를 빠트린것 같아 또 글을 쓰게 되었다. GitOps repo directories 일단 현 구성을 간략히 얘기하자면 하나의 applicationset에서 여러개의 application을 관리할 수 있도록 App of Apps 패턴을 사용하였고, gitops repo의 구성은 다음과 같다. app은 각 서비스에 대한 리소스들(deployment, service, hpa, configmap 등)을 넣어 두었고 common은 여러개의 서비스가 함께 사용하는 리소스들(ingress, limit-range, quota.. [argocd] argoCD로 배포 분리하기. 관련 주의할 점 및 이슈사항 정리 우리 회사는 codepipeline(source-codebuild)를 이용하여 서비스 배포를 하고 있는데, codebuild 에서 이미지 빌드 및 deployment 배포까지 수행하고 있었다. 이러한 구성에서 다음과 같은 문제점이 있었다. 1. 소스코드가 변경되어 빌드가 필요한 경우가 아닌 kubernetes resource만 변경이 있을때 배포만 다시 해도 되는데 빌드까지 다시 수행해야했다. 서비스별로 빌드하는데 시간은 차이가 있겠지만 작은 작업임에도 재배포하는데 10분정도 걸리는 경우도 있었다. 2. 전체 서비스의 배포상태를 한눈에 관리하기 어렵다. 스테이징 파이프라인만 70개 넘개 존재하는데 각 서비스들을 배포상태를 확인하기 위해 파이프라인을 하나씩 살펴봐야한다. 3. 누군가 kubectl 명령어 .. 이전 1 다음
