Kubernetes 개발용 Skaffold 개요

5년 반 전인 2018년 XNUMX월 XNUMX일, Google은 CI/CD용 오픈 소스 프로젝트의 첫 번째 알파 버전인 비계, 그의 목표는 개발자가 관리보다는 개발에 집중할 수 있도록 "간단하고 반복 가능한 Kubernetes 개발"을 만드는 것이었습니다. Skaffold의 흥미로운 점은 무엇인가요? 알고 보니 개발자는 물론 운영 엔지니어에게도 강력한 도구가 될 수 있는 몇 가지 요령이 숨어 있습니다. 프로젝트와 그 기능에 대해 알아 보겠습니다.

NB: 그건 그렇고, 우리는 이미 Skaffold에 대해 전반적으로 간략하게 이야기했습니다. 개발자 도구 검토, 그의 삶은 Kubernetes와 연결되어 있습니다.

이론. 목적과 역량

따라서 일반적으로 Skaffold는 CI/CD 주기(빌드, 푸시, 배포 단계) 자동화 문제를 해결하여 개발자에게 즉각적인 피드백을 제공합니다. Kubernetes 클러스터에서 실행되는 업데이트된 애플리케이션의 형태로 후속 코드 변경 결과를 신속하게 수신하는 기능. 또한 다양한 회로(개발, 단계, 프로덕션...)에서 작동할 수 있으며, Skaffold는 출시를 위한 해당 파이프라인을 설명하는 데 도움이 됩니다.

Skaffold의 소스 코드는 Go로 작성되었습니다. 배포자 무료 Apache License 2.0(GitHub)에 따라.

주요 기능과 특징을 살펴보겠습니다. 첫 번째에는 다음이 포함됩니다.

• Skaffold는 CI/CD 파이프라인 생성을 위한 도구를 제공합니다.
• 백그라운드에서 소스 코드의 변경 사항을 모니터링하고 코드를 컨테이너 이미지로 조합하고 이러한 이미지를 Docker 레지스트리에 게시하고 Kubernetes 클러스터에 배포하는 자동화된 프로세스를 실행할 수 있습니다.
• 저장소의 파일을 컨테이너의 작업 디렉터리와 동기화합니다.
• 컨테이너 구조 테스트를 사용하여 자동으로 테스트합니다.
• 포트를 전달합니다.
• 컨테이너에서 실행 중인 애플리케이션의 로그를 읽습니다.
• Java, Node.js, Python, Go로 작성된 애플리케이션 디버깅에 도움이 됩니다.

이제 기능에 대해:

• Skaffold 자체에는 클러스터 측 구성요소가 없습니다.. 즉, 이 유틸리티를 사용하기 위해 Kubernetes를 추가로 구성할 필요가 없습니다.
• 애플리케이션을 위한 다양한 파이프라인. 개발하는 동안 로컬 Minikube에 코드를 롤아웃한 다음 스테이지 또는 프로덕션으로 롤아웃해야 합니까? 이를 위해 다음이 있습니다. профили 그리고 하나의 애플리케이션에 대해 다양한 파이프라인을 설명할 수 있는 사용자 구성, 환경 변수 및 플래그가 있습니다.
• CLI. YAML의 콘솔 유틸리티 및 구성만 가능합니다. 인터넷에서 창작 시도에 대한 참고 자료를 찾을 수 있습니다. 실험적인 GUI그러나 현재 이것은 누군가가 그를 필요로 한다는 것을 의미할 가능성이 높지만 실제로는 그렇지 않습니다.
• 모듈성. Skaffold는 독립형 수확기가 아니지만 특정 작업에 개별 모듈이나 기존 솔루션을 사용하려고 노력합니다.

후자의 예시:

• 조립 단계에서 다음을 사용할 수 있습니다.
  • docker는 kaniko를 사용하는 클러스터 또는 Google Cloud Build에서 로컬로 빌드합니다.
  • 로컬로 Bazel;
  • 로컬로 또는 Google Cloud Build에서 Jib Maven 및 Jib Gradle
  • 사용자 정의 빌드 스크립트는 로컬에서 실행됩니다. 다른(더 유연하고 친숙한...) 빌드 솔루션을 실행해야 하는 경우 Skaffold가 이를 시작할 수 있도록 스크립트에 설명되어 있습니다(문서의 예). 이를 통해 스크립트를 사용하여 호출할 수 있는 모든 수집기를 사용할 수 있습니다.
• 테스트 단계에서는 이미 언급한 컨테이너 구조 테스트;
• 배포를 위해 다음이 제공됩니다.
  • Kubectl;
  • 지배;
  • 사용자 정의.

덕분에 Skaffold는 독특한 제품이라고 할 수 있습니다. CI/CD 구축을 위한 프레임워크. 다음은 이를 사용할 때의 예시 워크플로입니다(프로젝트 문서 참조).

Skaffold의 작업은 일반적으로 어떤 모습인가요?

1. 유틸리티는 소스 코드 디렉터리의 변경 사항을 모니터링합니다. 파일이 수정되면 Kubernetes 클러스터의 애플리케이션 포드와 동기화됩니다. 가능하다면 이미지를 재조립하지 않고 진행하세요. 그렇지 않으면 새 이미지가 조립됩니다.
2. 조립된 이미지는 컨테이너 구조 테스트를 사용하여 확인되고 태그가 지정되어 Docker 레지스트리로 전송됩니다.
3. 그런 다음 이미지가 배포됩니다(Kubernetes 클러스터에 배포됨).
4. 명령을 사용하여 실행이 초기화된 경우 skaffold dev, 그러면 애플리케이션에서 로그 수신을 시작하고 Skaffold는 변경사항이 모든 작업을 다시 반복할 때까지 기다립니다.

Skaffold 작동의 주요 단계에 대한 그림

관행. 비계 사용해보기

Skaffold의 사용법을 보여주기 위해 다음의 예를 들어보겠습니다. GitHub 프로젝트 저장소. 그건 그렇고 ibid 다양한 세부 사항을 고려한 다른 많은 예를 찾을 수 있습니다. Minikube에서 모든 작업을 로컬로 수행하겠습니다. 설치는 간단하고 몇 분 정도 소요됩니다. 시작하려면 kubectl이 필요합니다.

비계 설치:

curl -Lo skaffold https://storage.googleapis.com/skaffold/releases/latest/skaffold-linux-amd64
chmod +x skaffold
sudo mv skaffold /usr/local/bin
skaffold version
v0.37.1

필요한 예시를 사용하여 Skaffold 저장소를 복제해 보겠습니다.

git clone https://github.com/GoogleContainerTools/skaffold
cd skaffold/examples/microservices

저는 각각 하나의 작은 Go 애플리케이션을 포함하는 두 개의 포드가 있는 예제를 선택했습니다. 한 애플리케이션은 요청을 두 번째 애플리케이션인 백엔드(leeroy-app)로 리디렉션하는 프런트엔드(leeroy-web)입니다. 그것이 어떻게 보이는지 봅시다:

~/skaffold/examples/microservices # tree
.
├── leeroy-app
│   ├── app.go
│   ├── Dockerfile
│   └── kubernetes
│       └── deployment.yaml
├── leeroy-web
│   ├── Dockerfile
│   ├── kubernetes
│   │   └── deployment.yaml
│   └── web.go
├── README.adoc
└── skaffold.yaml
 
4 directories, 8 files

leeroy-app 및 leeroy-web에는 이 코드를 로컬로 빌드하기 위한 Go 코드와 간단한 Dockerfile이 포함되어 있습니다.

~/skaffold/examples/microservices # cat leeroy-app/Dockerfile
FROM golang:1.12.9-alpine3.10 as builder
COPY app.go .
RUN go build -o /app .
 
FROM alpine:3.10
CMD ["./app"]
COPY --from=builder /app .

애플리케이션 코드를 제공하지 않겠습니다. 그것만 알아도 충분합니다. leeroy-web 요청을 수락하고 이를 프록시로 처리합니다. leeroy-app. 그러므로 파일에 Deployment.yaml 에 대해서만 서비스가 있습니다 app (내부 라우팅용) 포드 포트 web 애플리케이션에 빠르게 액세스할 수 있도록 해당 정보를 우리 자신에게 전달하겠습니다.

모양 skaffold.yaml:

~/skaffold/examples/microservices # cat skaffold.yaml
apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
    - image: leeroy-web
      context: ./leeroy-web/
    - image: leeroy-app
      context: ./leeroy-app/
deploy:
  kubectl:
    manifests:
      - ./leeroy-web/kubernetes/*
      - ./leeroy-app/kubernetes/*
portForward:
  - resourceType: deployment
    resourceName: leeroy-web
    port: 8080
    localPort: 9000

위에서 언급한 모든 단계가 여기에 설명되어 있습니다. 이 구성 외에도 전역 설정이 포함된 파일도 있습니다. ~/.skaffold/config. 수동으로 또는 CLI를 통해 편집할 수 있습니다. 예를 들면 다음과 같습니다.

skaffold config set --global local-cluster true

이 명령은 전역 변수를 설정합니다 local-cluster 의미상 true, 이후에는 Skaffold가 원격 레지스트리에 이미지를 푸시하려고 시도하지 않습니다. 로컬로 개발하는 경우 이 명령을 사용하여 로컬로 이미지를 빌드할 수 있습니다.

돌아 가기 skaffold.yaml:

• 무대 위에 build 이미지를 로컬로 수집하고 저장해야 한다고 지정합니다. 빌드가 처음 실행되면 다음이 표시됩니다.

  // т.к. Minikube создает кластер в отдельной виртуальной машине,
  // придется проникнуть внутрь, чтобы найти образы
  # minikube ssh
  $ docker images
  REPOSITORY                                TAG                                                                IMAGE ID            CREATED             SIZE 
  leeroy-app                                7d55a50803590b2ff62e47e6f240723451f3ef6f8c89aeb83b34e661aa287d2e   7d55a5080359        4 hours ago         13MB 
  leeroy-app                                v0.37.1-171-g0270a0c-dirty                                         7d55a5080359        4 hours ago         13MB
  leeroy-web                                5063bfb29d984db1ff70661f17d6efcc5537f2bbe6aa6907004ad1ab38879681   5063bfb29d98        5 hours ago         13.1MB
  leeroy-web                                v0.37.1-171-g0270a0c-dirty                                         5063bfb29d98        5 hours ago         13.1MB

  보시다시피 Skaffold는 이미지에 직접 태그를 지정했습니다. 그런데 여러 태그 지정 정책이 지원됩니다.

• 추가로 구성에 표시됩니다 context: ./leeroy-app/, 즉. 이미지가 수집되는 컨텍스트가 지정됩니다.
• 배포 단계에서는 필요한 매니페스트에 kubectl과 마스크를 사용하기로 결정했습니다.
• PortForward: 일반적으로 다음을 사용하여 포트를 전달하는 방법과 유사합니다. kubectl port-forward, Skaffold에 이 명령어를 호출하라는 지침을 제공합니다. 이 경우 로컬 포트 ​​9000은 배포에서 이름이 8080으로 전달됩니다. leeroy-web.

발사할 시간이다 skaffold dev: 팀은 지속적인 "피드백 루프"를 생성합니다. 모든 것을 수집하여 클러스터에 배포할 뿐만 아니라 현재 포드 상태에 대해 알려주고 변경 사항을 모니터링하고 포드 상태를 업데이트합니다.

출시 결과는 다음과 같습니다. skaffold dev --port-forward 재조립할 때:

먼저 캐시가 사용되고 있는 것을 확인할 수 있습니다. 다음으로 애플리케이션이 조립 및 배포되고 포트가 전달됩니다. 지정된 이후 --port-forward, Skaffold가 포트를 다음으로 전달했습니다. web, 그가 요청한대로, 그러나 app 그는 자신의 재량에 따라 던졌습니다 (가장 가까운 무료 항목을 선택했습니다). 그런 다음 애플리케이션으로부터 첫 번째 로그를 받습니다.

작동하는지 확인해볼까요?

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-6998dfcc95-2nxvf   1/1     Running   0          103s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          103s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy app!!!

파일 수정 leeroy-app/app.go - 몇 초가 지나면...그리고:

~/skaffold/examples/microservices # kubectl get po
NAME                          READY   STATUS    RESTARTS   AGE
leeroy-app-ffd79d986-l6nwp    1/1     Running   0          11s
leeroy-web-69f7d47c9d-5ff77   1/1     Running   0          4m59s
~/skaffold/examples/microservices # curl localhost:9000
leeroooooy Habr!!!

동시에 Skaffold 자체는 한 가지 점을 제외하고 이전과 동일한 내용을 콘솔에 표시했습니다. leeroy-app, 그리고 한 번에 전부는 아닙니다.

더 많은 연습

새 프로젝트를 생성할 때 다음 명령을 사용하여 Skaffold 구성을 부트스트랩할 수 있다는 점도 언급할 가치가 있습니다. init, 매우 편리합니다. 또한 여러 구성을 작성할 수 있습니다. 기본 구성에서 개발을 수행한 다음 명령을 사용하여 단계적으로 롤아웃할 수 있습니다. run (같은 과정 dev, 변경 사항을 모니터링하지 않음), 다른 구성을 사용합니다.

카타코다에는 지도력 예를 들면 더욱 쉽습니다. 하지만 Kubernetes, 애플리케이션 및 Skaffold가 포함된 기성 샌드박스를 제공합니다. 아주 기본적인 것을 직접 시도해 보고 싶다면 훌륭한 옵션입니다.

Skaffold의 가능한 사용 사례 중 하나는 원격 클러스터에서 개발을 수행하는 것입니다. 모든 사람이 자신의 하드웨어에서 Minikube를 실행한 다음 애플리케이션을 출시하고 적절하게 작동할 것으로 기대하는 것을 편안하게 생각하지 않습니다. 이 경우 Skaffold는 문제를 완벽하게 해결합니다. 예를 들어 Reddit 엔지니어가 다음과 같이 확인할 수 있습니다. 이미 논의 писали 우리 블로그에서.

그리고에 이 간행물 Weaveworks에서 생산을 위한 파이프라인을 생성하는 예를 찾을 수 있습니다.

결론

Skaffold는 Kubernetes에 애플리케이션을 출시하는 것과 관련된 파이프라인을 구축하기 위한 편리한 도구이며 주로 개발 요구 사항에 중점을 둡니다. 개발자의 기본 요구 사항을 고려하는 "짧은" 파이프라인을 만드는 것이 매우 쉬울 뿐만 아니라 원하는 경우 더 큰 프로세스를 구성할 수도 있습니다. CI/CD 프로세스에서 Skaffold를 사용하는 명확한 예 중 하나로 주어진다 이러한 테스트 프로젝트 Kubernetes, gRPC, Istio 및 OpenCensus Tracing 기능을 사용하는 10개의 마이크로서비스 중 하나입니다.

Skaffold는 이미 GitHub에서 거의 8000개 이상의 별을 보유하고 있으며 Google에서 개발했으며 다음의 일부입니다. GoogleContainer도구 — 일반적으로 현재로서는 프로젝트가 앞으로도 계속 행복하게 발전할 것이라고 믿을 만한 충분한 이유가 있습니다.

PS

블로그에서도 읽어보세요.

• «Kubernetes에서 실행되는 애플리케이션 개발자를 위한 도구";
• «werf - Kubernetes의 CI/CD용 도구(개요 및 비디오 보고서)";
• «Garden v0.10.0: 노트북에는 Kubernetes가 필요하지 않습니다.";
• «Kubernetes 팁 및 요령: 로컬 개발 및 Telepresence 정보".

출처 : habr.com