# kaniko
Jenkins on k8s helm 배포 / Kaniko
젠킨스를 왜 eks에 올려야할까? 젠킨스를 eks에 올리면 좋은 점 : pod로 띄워서 slave가 빌드를 해줌 빌드 시작될때, slave를 동적으로 파드의 형태로 배포해서 해당 파드에서 빌드를 수행!!! RAM을 아낄수있따!!!! 라는 것 PV 및 SC생성 ebs irsa 생성같은것은 전 블로그 글 참조 helm 설치 ingress 생성 접속확인 빌드 확인 저렇게 젠킨스 젠킨스 slave친구들이 만들어졌다가 사라진다! 이제 PV를 붙혀서 slave친구들이 떨어뜨린 파일들을 저장해보자 helm values.yaml 수정 확인 pipeline 
클러스터 파이프라인구현 - 03 (파이프라인 스택 설치)
개요 구성한 파이프라인에 대해 설명한다. Stacks | stack | version | | --- | --- | | gitlab(helm) | gitlab-6.8.2 | | harbor(helm) | harbor-1.11.0 | | argo(helm) | argo-cd-5.23.1 | | Kaniko | v1.9.1 | Gitlab-runner GitLab CI/CD 파이프라인에서 사용, GitLab 서버와 연결되어 파이프라인의 작업을 실행합니다. Harbor 여기선 docker registry 역할만 수행합니다. KANIKO 카니코를 처음 접한 사람들도 있을 것이다. 보통 컨테이너하면 도커를 많이 생각할 것이다. 아래 내용은 클러스터에서 도커를 이용한 빌드보다
[Jenkins] 도커/쿠버네티스에서 파이프라인 구축 & kaniko & ArgoCD
도커에서 pipeline 구축 도커허브 저장소에 push하기 위해서는 도커허브에서 설정을 해줘야한다. AccountSetting -> Security -> New Access Tocken 이름: For Jenkins 설정: Read & Write 생성한 이후 토큰값은 복사해서 저장해둔다. 화면을 닫으면 사라지므로 주의 젠킨스에서 토큰을 가져올 수 있는 자격증명 만들기 젠킨스 관리 -> Manage Credentials -> global -> add Credentials Kind: Username with passw
쿠버네티스 전문가 양성과정 12주차 3일(3/8)
Jenkins with EKS EKS설치 및 Jenkins올리기 1 . Deploy EKS eksctl create cluster --name myeks --region ap-northeast-2 --version 1.24 --instance-types t3.medium eksctl utils associate-iam-oidc-provider --cluster myeks --approve eksctl create iamserviceaccount \ --name ebs-csi-controller-sa \ --namespace kube-system \ --cluster myeks \ --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \ --approve \ --role-only \
Kubernets CI/CD 구축( Jenkins,ArgoCD,kaniko,harbor)
1. Overviews Kubernetes에서 CI/CD 를 테스트 한 내용을 기록합니다. 기존 작성한 Kubernetes CI/CD 글의 경우 Jenkins만 이용하였지만,이번 테스트에서는 일반적으로 많이 사용하는 Jenkins-ArgoCD 조합을 사용하여 파이프라인을 구성하고 Docker build를 위해 Kaniko를 이용합니다. 또한 Github에서 webhook을 설정해 push가 발생하였을 때 trigger가 발생해 자동화가 되도록 설정하였습니다. 전체적인 플로우는 다음과 같습니다. 
Docker Build 서버 구축하기(docker 원격접속, kaniko)
1. Overview 컨테이너 기반의 서비스를 사용할 때 이미지 빌드 서버를 따로 구축하는 경우가 있습니다. 일반적으로 개발자는 도커나,containerd 가 설치되어 있는 환경에서 CLI를 통해 이미지를 빌드하지만 서비스 레이어에서 User가 이미지를 빌드하는 경우가 생깁니다. 예를 들어 Kubeflow에서 사용자가 노트북을 통해 작업을 하고 해당 노트북을 공유하기 위해 이미지를 저장하는 경우가 생깁니다. 서비스와 같은 환경에서 빌드를 진행할 경우 사용자가 적고, 이미지 빌드 작업이 리소스를 별로 사용하지 않으면 문제가 없지만, 많은 리소스를 사용할 경우 빌드하는데 리소스를 많이 사용해 기존 서비스나 서버의 프로세스에 영향을 끼칠 수 있기 때문에 외부 빌드 서버를 따로 구축합니다. 일반적으로 VM이나 서버를 따로 구축해 Container runtime(dockerd,containerd)만 설치하여 빌드 서버로 사용합니다. *2. Docker