시작해보자
모든 컴퓨터에서 웹 앱을 사용할 수 있으려면 컨테이너화해야 하며, 컨테이너화가 docker보다 가장 좋은 경우에는 컨테이너화가 필요합니다.
앱을 실행하기 위해 Dockerfile을 만들었지만 다단계 형식을 사용했습니다
이유는 간단합니다. 단일 단계에서 이미지를 생성하면 머신에서 더 많은 공간을 소비하는 반면, 다단계 빌드를 사용하면 빌드 환경과 런타임 환경을 분리하여 이미지의 최종 크기를 최적화하고 공격도 줄입니다. 더 나은 보안을 위해 이미지를 노출하세요
이렇게 할 수 있습니다
# Start with a base image FROM golang:1.22 as base WORKDIR /app COPY go.mod ./ RUN go mod download COPY . . RUN go build -o main . ####################################################### # Reduce the image size using multi-stage builds # We will use a distroless image to run the application FROM gcr.io/distroless/base # Copy the binary from the previous stage COPY --from=base /app/main . # Copy the static files from the previous stage COPY --from=base /app/static ./static # Expose the port on which the application will run EXPOSE 8080 # Command to run the application CMD ["./main"]
이제 dockerfile이 있으므로 이를 빌드하고 dockerhub에 배포해 보겠습니다.
docker build -t pankaj892/webapp:v1 .
앱이 로컬 컴퓨터에서 예상대로 작동하는지 확인하려고 합니다
docker run -p 8080:8080 pankaj892-webapp:v1
dockerhub에 푸시해 보겠습니다
docker push pankaj892/webapp:v1 .
mininkube/kind를 사용하여 로컬로 클러스터를 생성하거나 클라우드에서 관리형 솔루션 중 하나를 사용할 수 있습니다. 저는 AWS의 Elastic Kubernetes Service(EKS)를 사용할 예정입니다.
콘솔이나 명령줄을 사용하여 EKS에서 클러스터를 시작할 수 있습니다. 저는 명령줄을 사용하겠습니다
eksctl create cluster--instance-selector-vcpus=2 --instance-selector-memory=4 --name <name-of-cluster> --region <region-code>
이렇게 하면 vCPU가 2개이고 메모리가 4GB인 노드 그룹의 머신 유형만 선택됩니다
모든 리소스를 하나씩 배포할 수 있지만 규모가 커지면 관리하기가 어려울 것입니다. 여기서 Helm은 차트를 사용하여 모든 리소스를 관리하는 패키지 관리자 역할을 합니다.
헬름 차트 만들기
# Start with a base image FROM golang:1.22 as base WORKDIR /app COPY go.mod ./ RUN go mod download COPY . . RUN go build -o main . ####################################################### # Reduce the image size using multi-stage builds # We will use a distroless image to run the application FROM gcr.io/distroless/base # Copy the binary from the previous stage COPY --from=base /app/main . # Copy the static files from the previous stage COPY --from=base /app/static ./static # Expose the port on which the application will run EXPOSE 8080 # Command to run the application CMD ["./main"]
Helm은 우리가 사용할 파일을 생성하지만 우리 프로젝트에는 대부분의 파일이 필요하지 않습니다.
다음 파일을 생성하고 helm 디렉토리에 추가하세요
배포
eksctl create cluster--instance-selector-vcpus=2 --instance-selector-memory=4 --name <name-of-cluster> --region <region-code>
서비스
helm create web-app
인그레스
# This is a sample deployment manifest file for a simple web application. apiVersion: apps/v1 kind: Deployment metadata: name: web-app labels: app: web-app spec: replicas: 1 selector: matchLabels: app: web-app template: metadata: labels: app: web-app spec: containers: - name: web-app image: {{ .Values.image.repository }}:{{ .Values.image.tag }} ports: - containerPort: 8080
값 파일을 다음으로 업데이트하세요
# Service for the application apiVersion: v1 kind: Service metadata: name: web-app labels: app: web-app spec: ports: - port: 80 targetPort: 8080 protocol: TCP selector: app: web-app type: ClusterIP
이제 투구 부분이 완료되었으며 CI 배포로 넘어갑니다
Github Actions를 사용하면 push, pull과 같은 저장소의 일부 이벤트를 기반으로 앱 빌드 프로세스를 자동화할 수 있습니다.
파이프라인 파일을 만들어 보겠습니다
워크플로 파일은 (.github/workflows/cicd.yml)
에 저장됩니다.
# Ingress resource for the application apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-app annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: nginx rules: - host: web-app.local http: paths: - path: / pathType: Prefix backend: service: name: web-app port: number: 80
이 워크플로 파일은 먼저 dockerfile에서 이미지를 빌드한 다음 dockerhub에 푸시한 다음 helm의charts.yaml 파일에 있는 이미지 태그를 업데이트합니다.
argocd는 git repo에서 변경 사항을 가져와 앱에서 업데이트할 수 있으므로 CD 파이프라인에 argocd를 사용할 것입니다.
클러스터에 argocd를 설치해 보겠습니다
kubectl은 네임스페이스 argocd를 생성합니다
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
argocd 서버에 액세스하려면 서비스를 로드밸런서 유형으로 변경해야 합니다
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
Windows의 경우
입니다.
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'
작동하지 않으면 kubectl을 통해 서비스를 편집하고 유형을 LoadBalancer로 변경하면 작동합니다
이제 서비스 IP를 받아보세요
kubectl get svc argocd-server -n argocd
IP를 얻었지만 argocd에 로그인하려면 비밀번호가 필요합니다
kubectl 비밀 가져오기 argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 --디코드
이 명령은 비밀번호가 base64 형식으로 인코딩되므로 비밀번호를 가져오고 비밀번호를 디코딩합니다
로그인한 후 새 프로젝트 > 프로젝트 이름 추가 > argocd가 저장소를 동기화할 수 있도록 저장소를 추가하세요 argocd는 자동으로 값 파일을 찾고 제출을 클릭한 후 해당 파일을 선택합니다
파이프라인을 구축했지만 앱에 액세스하는 방법은 액세스할 때마다 EKS의 클러스터 URL에 넣을 수 없으므로 이를 위해 인그레스를 사용해야 합니다
앱에 액세스하기 위해 AWS의 Nginx Ingress를 사용하고 있습니다
클러스터에 수신 배포
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.11.1/deploy/static/provider/aws/deploy.yaml
이제 수신이 배포되었으며 EKS의 클러스터 IP를 Linux용 로컬 호스트 파일, Windows용 /etc/hosts(C:WindowsSystem32etchosts에 있음)에 추가해야 합니다.
# Start with a base image FROM golang:1.22 as base WORKDIR /app COPY go.mod ./ RUN go mod download COPY . . RUN go build -o main . ####################################################### # Reduce the image size using multi-stage builds # We will use a distroless image to run the application FROM gcr.io/distroless/base # Copy the binary from the previous stage COPY --from=base /app/main . # Copy the static files from the previous stage COPY --from=base /app/static ./static # Expose the port on which the application will run EXPOSE 8080 # Command to run the application CMD ["./main"]
이제 web-app.local에서 앱에 액세스할 수 있습니다
모든 단계를 완료하여 앱을 테스트했습니다
보시다시피 상단의 URL은 호스트 파일에 정의한 것입니다
앱이 실행 중입니다. 무언가를 추가하고 리포지토리에 커밋하면 argocd가 해당 변경 사항을 선택하여 앱에 배포할 수 있습니다.
저장소를 변경했는데 이로 인해 파이프라인이 실행됩니다
파이프라인이 시작되었으며 완료 후 argocd가 해당 변경 사항을 적용하는지 확인합니다
예, 앱에 변경 사항이 있습니다 argocd가 변경 사항을 선택하고 앱을 최신 변경 사항과 동기화했습니다
여기까지 오셨다면 축하드립니다!!!
이 프로젝트는 AWS에 kubernetes를 배포하는 것부터 파이프라인과 배포를 생성하고 문제를 해결하는 것까지 나에게 훌륭한 학습 경험이었습니다. 이 프로젝트는 Go 앱을 위한 엔드투엔드 DevOps 파이프라인을 만드는 데 도움이 되었으며 필요에 따라 확장할 수 있습니다. Terraform 또는 Cloudformation 스택을 사용하여 eks clutser를 배포하는 등 더 많은 것을 탐색하고 더 개선할 계획입니다.
어딘가에 막히면 이 저장소를 참조할 수 있습니다
이 파이프라인을 구축한 경험이 어땠는지 댓글로 알려주세요.
위 내용은 Gitops 및 Kubernetes를 사용하는 Golang 웹 앱의 Devops 파이프라인의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!