플러그인, SMS, 등록 없이 GKE에서 배포 작업을 생성합니다. 젠킨스의 재킷 속을 들여다보자

우리 개발 팀 중 한 팀의 팀장이 전날 컨테이너화된 새로운 애플리케이션을 테스트해 달라고 요청했을 때 모든 것이 시작되었습니다. 나는 그것을 게시했다. 약 20분 후 애플리케이션 업데이트 요청이 접수되었습니다. 거기에 꼭 필요한 항목이 추가되었기 때문입니다. 나는 갱신했다. 몇 시간이 더 지나면... 음, 다음에 무슨 일이 일어나기 시작했는지 짐작할 수 있을 것입니다...

나는 꽤 게으르다는 것을 인정해야 합니다. (이전에 이것을 인정하지 않았나요? 아니요?) 팀 리더가 모든 CI/CD가 있는 Jenkins에 액세스할 수 있다는 사실을 고려하여 저는 다음과 같이 생각했습니다. 그가 원하는 만큼! 나는 농담을 기억했습니다. 사람에게 물고기를 주면 하루 동안 먹을 것입니다. 사람에게 Fed를 부르면 그는 평생 Fed를 받게 될 것입니다. 그리고 갔다 직장에서 장난을 치다, 성공적으로 구축된 버전의 애플리케이션이 포함된 컨테이너를 Kuber에 배포하고 모든 값을 컨테이너로 전송할 수 있습니다. ENV (과거에 영어 교사였던 문헌학자였던 나의 할아버지는 이제 이 문장을 읽은 후 관자놀이에서 손가락을 돌리며 나를 매우 표정있게 바라보곤 했습니다).

그래서 이 노트에서는 제가 어떻게 배웠는지 말씀드리겠습니다.

1. 작업 자체 또는 다른 작업에서 Jenkins의 작업을 동적으로 업데이트합니다.
2. Jenkins 에이전트가 설치된 노드에서 클라우드 콘솔(Cloud Shell)에 연결합니다.
3. Google Kubernetes Engine에 워크로드를 배포합니다.

사실 저는 물론 다소 솔직하지 못한 편입니다. 귀하는 Google 클라우드에 인프라의 적어도 일부를 보유하고 있으므로 해당 사용자이며 물론 GCP 계정을 가지고 있다고 가정합니다. 하지만 이 메모의 내용은 그게 아닙니다.

이것은 나의 다음 치트 시트입니다. 나는 한 가지 경우에만 그러한 메모를 작성하고 싶습니다. 문제에 직면했고 처음에는 해결 방법을 몰랐고 솔루션이 기성품으로 검색되지 않았기 때문에 부분적으로 검색하여 결국 문제를 해결했습니다. 그래서 나중에 내가 어떻게 했는지 잊어버렸을 때 모든 것을 다시 구글링해서 모아서 정리할 필요 없이 스스로 그런 치트 시트를 작성합니다.

부인 성명: 1. 메모는 역할에 대해 "나 자신을 위해" 작성되었습니다. 가장 좋은 방법 적용되지 않습니다. 댓글에서 "이렇게 하면 더 좋았을 텐데"라는 옵션을 읽게 되어 기쁩니다.
2. 노트의 적용된 부분이 소금으로 간주된다면 이전 노트와 마찬가지로 이 노트도 약한 소금 용액입니다.

Jenkins에서 작업 설정을 동적으로 업데이트

귀하의 질문이 예상됩니다. 동적 작업 업데이트가 그것과 어떤 관련이 있습니까? 문자열 매개변수의 값을 수동으로 입력하면 됩니다!

저는 정말 게으릅니다. 그들이 불평하는 것이 마음에 들지 않습니다. Misha, 배포가 중단되고 모든 것이 사라졌습니다! 살펴보기 시작했는데 일부 작업 시작 매개변수 값에 오타가 있습니다. 그러므로 나는 모든 일을 가능한 한 효율적으로 수행하는 것을 선호합니다. 대신 선택할 값 목록을 제공하여 사용자가 데이터를 직접 입력하는 것을 방지할 수 있다면 선택 항목을 구성합니다.

계획은 다음과 같습니다. Jenkins에서 작업을 생성합니다. 작업을 시작하기 전에 목록에서 버전을 선택하고 다음을 통해 컨테이너에 전달되는 매개변수의 값을 지정할 수 있습니다. ENV, 그런 다음 컨테이너를 수집하여 Container Registry에 푸시합니다. 그런 다음 거기에서 컨테이너는 다음과 같이 Cuber에서 시작됩니다. 작업량 작업에 지정된 매개변수를 사용합니다.

Jenkins에서 작업을 생성하고 설정하는 프로세스는 고려하지 않을 것입니다. 이는 주제에서 벗어납니다. 작업이 준비되었다고 가정하겠습니다. 버전이 포함된 업데이트된 목록을 구현하려면 두 가지가 필요합니다. 즉, 사전에 유효한 버전 번호가 있는 기존 소스 목록과 다음과 같은 변수가 필요합니다. 선택 매개변수 작업에서. 이 예에서는 변수 이름을 지정하겠습니다. BUILD_VERSION, 우리는 그것에 대해 자세히 다루지 않을 것입니다. 하지만 소스 목록을 자세히 살펴 보겠습니다.

옵션이 그리 많지 않습니다. 즉시 두 가지가 떠올랐습니다.

• Jenkins가 사용자에게 제공하는 원격 액세스 API를 사용하세요.
• 원격 저장소 폴더의 콘텐츠를 요청합니다(이 경우 JFrog Artifactory이며 중요하지 않습니다).

젠킨스 원격 액세스 API

확립된 우수한 전통에 따르면, 긴 설명은 피하고 싶습니다.
나는 첫 번째 단락의 일부만 무료로 번역하도록 허용하겠습니다. API 문서의 첫 번째 페이지:

Jenkins는 해당 기능에 대한 원격 기계 판독 가능 액세스를 위한 API를 제공합니다. <…> 원격 액세스는 REST와 유사한 스타일로 제공됩니다. 즉, 모든 기능에 대한 단일 진입점이 없고 대신 '.../api/", 어디 "..."는 API 기능이 적용되는 개체를 의미합니다.

즉, 현재 이야기하고 있는 배포 작업이 다음 위치에서 사용 가능한 경우 http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, 이 작업에 대한 API 휘파람을 다음에서 사용할 수 있습니다. http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

다음으로, 출력을 어떤 형식으로 받을지 선택할 수 있습니다. 이 경우 API는 필터링만 허용하므로 XML에 중점을 두겠습니다.

모든 작업 실행 목록을 가져오도록 하겠습니다. 우리는 어셈블리 이름(이름 표시하기) 및 그 결과(결과):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

그것은 밝혀졌다?

이제 결과가 나오는 실행만 필터링해 보겠습니다. 성공. 논증을 활용해보자 &들어오지 못하게 하다 매개변수로 다음과 같지 않은 값의 경로를 전달합니다. 성공. 예 예. 이중 부정은 진술입니다. 우리는 관심이 없는 모든 것을 제외합니다.

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

성공 목록 스크린샷

글쎄, 재미로 필터가 우리를 속이지 않았는지 확인하고(필터는 거짓말을 하지 않습니다!) "실패한" 목록을 표시해 보겠습니다.

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

실패한 목록의 스크린샷

원격 서버에 있는 폴더의 버전 목록

버전 목록을 얻는 두 번째 방법이 있습니다. Jenkins API에 액세스하는 것보다 훨씬 더 마음에 듭니다. 응용 프로그램이 성공적으로 빌드되면 해당 응용 프로그램이 패키지되어 저장소의 적절한 폴더에 배치되었음을 의미하기 때문입니다. 마찬가지로 저장소는 작업 중인 애플리케이션 버전의 기본 저장소입니다. 좋다. 그럼, 그에게 어떤 버전이 저장되어 있는지 물어봅시다. 원격 폴더를 컬링하고, grep하고, awk하겠습니다. 누구든지 oneliner에 관심이 있다면 스포일러 아래에 있습니다.

한 줄 명령
두 가지 사항에 유의하십시오. 헤더에 연결 세부 정보를 전달하며 폴더의 모든 버전이 필요하지 않으며 한 달 이내에 생성된 버전만 선택합니다. 현실과 필요에 맞게 명령을 편집하십시오.

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

Jenkins에서 작업 및 작업 구성 파일 설정

버전 목록의 출처를 알아냈습니다. 이제 결과 목록을 작업에 통합해 보겠습니다. 나에게 있어 확실한 해결책은 애플리케이션 빌드 작업에 단계를 추가하는 것이었습니다. 결과가 "성공"인 경우 실행될 단계입니다.

조립 작업 설정을 열고 맨 아래로 스크롤하십시오. 버튼을 클릭하세요: 빌드 단계 추가 -> 조건부 단계(단일). 단계 설정에서 조건을 선택하세요. 현재 빌드 상태, 값을 설정 성공, 성공할 경우 수행할 작업 쉘 명령 실행.

이제 재미있는 부분입니다. Jenkins는 작업 구성을 파일에 저장합니다. XML 형식입니다. 길을 따라 http://путь-до-задания/config.xml 따라서 구성 파일을 다운로드하고 필요에 따라 편집한 후 원래 위치에 다시 넣을 수 있습니다.

버전 목록에 대한 매개변수를 생성하기로 위에서 동의했다는 점을 기억하세요. BUILD_VERSION?

구성 파일을 다운로드하고 그 내용을 살펴보겠습니다. 매개변수가 제자리에 있고 원하는 유형인지 확인하기만 하면 됩니다.

스포일러 아래 스크린샷.

config.xml 조각은 동일하게 표시되어야 합니다. Choices 요소의 내용이 아직 누락된 것을 제외하고

확실합니까? 이제 빌드가 성공하면 실행될 스크립트를 작성해 보겠습니다.
스크립트는 버전 목록을 수신하고, 구성 파일을 다운로드하고, 필요한 위치에 버전 목록을 작성한 다음 다시 넣습니다. 예. 좋아요. 버전 목록이 이미 있는 곳에 XML로 버전 목록을 작성합니다(향후 스크립트를 처음 시작한 후 작성 예정). 나는 세상에 아직도 정규식을 열광적으로 좋아하는 사람들이 있다는 것을 알고 있습니다. 나는 그들에게 속하지 않습니다. 설치해주세요 xmlstarler 구성이 편집될 머신에. sed를 사용하여 XML을 편집하는 것을 피하기 위해 지불해야 할 큰 대가는 아닌 것 같습니다.

스포일러 아래에는 위의 시퀀스를 전체적으로 수행하는 코드를 제시합니다.

원격 서버의 폴더에 있는 버전 목록을 구성에 씁니다.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Jenkins에서 버전을 얻는 옵션을 선호하고 나만큼 게으른 경우 스포일러 아래에 동일한 코드가 있지만 Jenkins의 목록은 다음과 같습니다.

Jenkins의 버전 목록을 구성에 작성합니다.
이것만 기억하세요. 내 어셈블리 이름은 콜론으로 구분된 시퀀스 번호와 버전 번호로 구성됩니다. 따라서 awk는 불필요한 부분을 잘라냅니다. 자신의 필요에 맞게 이 행을 변경하십시오.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

이론적으로 위 예제를 기반으로 작성된 코드를 테스트했다면 배포 작업에 버전이 포함된 드롭다운 목록이 이미 있어야 합니다. 스포일러 아래 스크린샷과 같습니다.

올바르게 완료된 버전 목록

모든 것이 작동했다면 스크립트를 복사하여 붙여 넣으십시오. 쉘 명령 실행 변경 사항을 저장합니다.

Cloud Shell에 연결

컨테이너에 수집가가 있습니다. 우리는 애플리케이션 제공 도구 및 구성 관리자로 Ansible을 사용합니다. 따라서 컨테이너를 구축할 때 염두에 두어야 할 세 가지 옵션은 Docker에 Docker를 설치하거나, ​​Ansible을 실행하는 머신에 Docker를 설치하거나, ​​클라우드 콘솔에서 컨테이너를 구축하는 것입니다. 우리는 이 기사에서 Jenkins용 플러그인에 대해 침묵을 유지하기로 동의했습니다. 기억하다?

저는 다음과 같이 결정했습니다. "즉시 사용 가능한" 컨테이너를 클라우드 콘솔에 수집할 수 있으므로 굳이 귀찮게 할 이유가 있을까요? 깨끗하게 유지하세요, 그렇죠? 클라우드 콘솔에서 Jenkins 컨테이너를 수집한 다음 거기에서 큐브로 실행하고 싶습니다. 또한 Google은 인프라 내에 매우 풍부한 채널을 보유하고 있어 배포 속도에 유익한 영향을 미칠 것입니다.

클라우드 콘솔에 연결하려면 다음 두 가지가 필요합니다. 지클라우드 및 액세스 권한 Google 클라우드 API 이와 동일한 연결이 이루어질 VM 인스턴스의 경우.

Google Cloud가 아닌 연결을 계획하고 있는 분들을 위해
Google은 서비스에서 대화형 인증을 비활성화할 수 있는 가능성을 허용합니다. 이렇게 하면 *nix를 실행 중이고 콘솔 자체가 있는 경우 커피 머신에서도 콘솔에 연결할 수 있습니다.

이 노트의 틀 내에서 이 문제를 더 자세히 다루어야 할 필요가 있다면 의견을 적어주세요. 충분한 표를 얻으면 이 주제에 대한 업데이트를 작성하겠습니다.

권한을 부여하는 가장 쉬운 방법은 웹 인터페이스를 이용하는 것입니다.

1. 이후에 클라우드 콘솔에 연결할 VM 인스턴스를 중지합니다.
2. 인스턴스 세부정보를 열고 클릭하세요. 수정.
3. 페이지 맨 아래에서 인스턴스 액세스 범위를 선택합니다. 모든 Cloud API에 대한 전체 액세스 권한.

   스크린 샷
   

4. 변경 사항을 저장하고 인스턴스를 시작합니다.

VM 로드가 완료되면 SSH를 통해 VM에 연결하고 오류 없이 연결되는지 확인합니다. 다음 명령을 사용하십시오.

gcloud alpha cloud-shell ssh

성공적인 연결은 다음과 같습니다

GKE에 배포

우리는 IaC(Infrastucture as a Code)로 완전히 전환하기 위해 가능한 모든 노력을 기울이고 있으므로 docker 파일은 Git에 저장됩니다. 이것은 한편입니다. 그리고 쿠버네티스에서의 배포는 이 작업에서만 사용되는 yaml 파일로 설명되며, 그 자체도 코드와 같습니다. 이것은 반대편에서 온 것입니다. 일반적으로 계획은 다음과 같습니다.

1. 우리는 변수의 값을 취합니다 BUILD_VERSION 그리고 선택적으로 전달될 변수의 값 ENV.
2. Git에서 dockerfile을 다운로드합니다.
3. 배포용 yaml을 생성합니다.
4. scp를 통해 이 두 파일을 모두 클라우드 콘솔에 업로드합니다.
5. 거기에 컨테이너를 빌드하고 컨테이너 레지스트리에 푸시합니다.
6. 로드 배포 파일을 큐브에 적용합니다.

좀 더 구체적으로 설명해보자. 일단 우리가 이야기를 시작하자 ENV, 다음 두 매개변수의 값을 전달해야 한다고 가정해 보겠습니다. 매개변수1 и 매개변수2. 배포 작업을 추가하고 다음을 입력합니다. 문자열 매개변수.

스크린 샷

간단한 리디렉션으로 yaml을 생성하겠습니다. 에코 파일로. 물론 dockerfile에 다음이 있다고 가정합니다. 매개변수1 и 매개변수2로드 이름은 다음과 같습니다. 굉장한 앱, 지정된 버전을 적용한 조립된 컨테이너는 다음 위치에 있습니다. 컨테이너 레지스트리 도중에 gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION어디에서 $BUILD_VERSION 드롭다운 목록에서 이(가) 선택되었습니다.

팀 목록

touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo "  name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo "  replicas: 1" >> deploy.yaml
echo "  selector:" >> deploy.yaml
echo "    matchLabels:" >> deploy.yaml
echo "      run: awesomeapp" >> deploy.yaml
echo "  template:" >> deploy.yaml
echo "    metadata:" >> deploy.yaml
echo "      labels:" >> deploy.yaml
echo "        run: awesomeapp" >> deploy.yaml
echo "    spec:" >> deploy.yaml
echo "      containers:" >> deploy.yaml
echo "      - name: awesomeapp" >> deploy.yaml
echo "        image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo "        env:" >> deploy.yaml
echo "        - name: PARAM1" >> deploy.yaml
echo "          value: $PARAM1" >> deploy.yaml
echo "        - name: PARAM2" >> deploy.yaml
echo "          value: $PARAM2" >> deploy.yaml

다음을 사용하여 연결한 후 Jenkins 에이전트 gcloud 알파 cloud-shell SSH 대화형 모드를 사용할 수 없으므로 매개변수를 사용하여 클라우드 콘솔에 명령을 보냅니다. --명령.

이전 dockerfile에서 클라우드 콘솔의 홈 폴더를 정리합니다.

gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"

scp를 사용하여 새로 다운로드한 dockerfile을 클라우드 콘솔의 홈 폴더에 배치합니다.

gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~

컨테이너를 수집하고, 태그를 지정하고, Container Registry에 푸시합니다.

gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"

배포 파일에서도 동일한 작업을 수행합니다. 아래 명령은 배포가 발생하는 클러스터의 가상 이름을 사용합니다(awsm-클러스터) 및 프로젝트 이름(멋진 프로젝트), 클러스터가 있는 위치입니다.

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"

작업을 실행하고 콘솔 출력을 열고 컨테이너가 성공적으로 조립되었는지 확인하기를 바랍니다.

스크린 샷

그리고 조립된 컨테이너의 성공적인 배포

스크린 샷

일부러 설정을 무시했어요 입구. 한 가지 간단한 이유는 다음과 같습니다. 일단 설정하면 작업량 지정된 이름을 사용하면 이 이름으로 배포를 수행하는 횟수에 관계없이 계속 작동합니다. 글쎄, 일반적으로 이것은 역사의 범위를 조금 넘어서는 것입니다.

결론 대신

위의 모든 단계를 완료할 수는 없었지만 Jenkins의 muuulion용 플러그인을 설치하기만 하면 됩니다. 하지만 어떤 이유에서인지 나는 플러그인을 좋아하지 않습니다. 글쎄, 더 정확하게는 나는 절망 때문에 그들에게 의지합니다.

그리고 저는 저를 위해 새로운 주제를 선택하는 것을 좋아합니다. 위의 텍스트는 맨 처음에 설명한 문제를 해결하면서 얻은 결과를 공유하는 방법이기도 합니다. 그와 같이 데브옵스에서 전혀 무서운 늑대가 아닌 사람들과 공유하세요. 내 연구 결과가 적어도 누군가에게 도움이 된다면 나는 기뻐할 것입니다.

출처 : habr.com