프레젠테이션을 위한 지속적인 전달 – 2/2

이 기사 시리즈의 첫 번째 부분에서는 사용 사례와 reveal.js를 사용한 프레젠테이션의 이점을 보여줍니다. 즉, Docs As Code이므로 버전 제어에 배치할 수 있으며 물론 지속적인 제공을 통해서도 제공할 수 있습니다. 또한 예시적인 구체적인 구현은 Jenkins를 사용하여 GitHub 페이지에 파이프라인을 배포하는 방법을 보여줍니다. 이 부분은 배치(Sonatype Nexus 및 Kubernetes)에 대한 추가 대안을 보여줍니다. Jenkinsfile 같은 것이 남아 있습니다.

넥서스에 배포

Maven mvn = new MavenInDocker(this, "3.5.0-jdk-8")
String versionName = createVersion(mvn)

stage('Deploy Nexus') {
    mvn.useDeploymentRepository([
            id: 'ecosystem.cloudogu.com',
            CredentialsId: 'ces-nexus'
    ])

    mvn.deploySiteToNexus("-Dartifact=${env.BRANCH_NAME} ")
}

비공개 컨텍스트(예: 회사 내부 프레젠테이션)에서는 GitHub의 공개 배포가 옵션이 아닙니다. Nexus 리포지토리가 이미 내부적으로 사용 가능한 경우 Maven 사이트 메커니즘을 사용하여 프레젠테이션을 업로드할 수 있습니다.

이를 위해 당신은 필요합니다

  • 넥서스 저장소 임 raw 형식(예: Cloudogu-Docs),
  • 하나 pom.xml기본적으로 사이트가 배포되는 위치를 구성하고
  • Nexus 리포지토리에 대한 쓰기 권한이 있는 사용자 계정.

일반적으로 다음을 사용하여 Maven 사이트를 배포합니다. mvn site:deploy. 사용자 계정과 비밀번호는 settings.xml. 경험에 따르면 후자는 CI 서버에서 번거롭습니다. 다시 구현 세부 사항은 ces-build-lib에 남겨두고 Maven.deploySiteToNexus() 단계를 간단히 호출합니다. 다시 말하지만 Docker는 ces-build-lib의 MavenInDocker 클래스를 사용하여 Maven을 배포하는 데 사용됩니다.

이것이 작동하려면 먼저 다음을 사용해야 합니다. Maven.deploySiteToNexus() 다음이 통과됩니다.

  • 리포지토리의 ID( pom.xml아래 참조) 및
  • 의 신분증 Username with password Jenkins에서 유지되는 자격 증명. 예제에서는 ces-nexus. CredentialsId: 'ces-nexus'. 이들은 저장소에 기록될 역할을 통해 권한이 부여된 Nexus의 사용자에게 속합니다. Nexus 3에서 역할에는 특히 권한이 필요합니다. nx-repository-view-raw-<RepoName>-add 그리고 -edit (예: nx-repository-view-raw-Cloudogu-Docs-add).

주요 포인트는 pom.xml 다음과 같습니다(전체 예제는 GitHub 참조).

<groupId>com.cloudogu.slides</groupId>
<artifactId>${artifact}</artifactId>
<version>${revision}</version>
<packaging>pom</packaging>

<url>https://ecosystem.cloudogu.com/nexus/repository/Cloudogu-Docs/${project.groupId}/${project.artifactId}/${project.version}/</url>

<distributionManagement>
    <site>
        <id>ecosystem.cloudogu.com</id>
        <name>site repository ecosystem.cloudogu.com</name>
        <url>dav:https://ecosystem.cloudogu.com/nexus/repository/Cloudogu-Docs/${project.groupId}/${project.artifactId}/${project.version}/</url>
    </site>
</distributionManagement>

<properties>
    <revision>-SNAPSHOT</revision>
    <artifact>template</artifact>
</properties>

Maven 좌표(groupId, artifactId 그리고 version)는 여기에서 Nexus 저장소의 프레젠테이션 URL을 정의하는 데 사용됩니다. 날짜가 있는 URL master 예를 들어 배포된 버전의 분기는 다음과 같습니다.
https://ecosystem.cloudogu.com/nexus/repository/Cloudogu-Docs/com.cloudogu.slides/master/201904291351-dd1df3d7/

Maven 기능 “CI 친화적 버전”은 시스템 속성을 사용하여 빌드하는 동안 동적으로 좌표를 설정하는 데 사용됩니다(명령줄에서, 예를 들어 -Dartifact=abc) 설정:

  • artifactId 현재 브랜치의 이름을 URL에 매핑하는 데 사용됩니다(각 브랜치에 고유한 URL 제공).
  • revision 각 빌드에서 다시 계산되는 버전을 설정합니다. 값은 이미
    createVersion() 인계됨(기사 시리즈의 첫 번째 부분 참조):
    mvn.additionalArgs = "-Drevision=${versionName} "

쿠버네티스에 배포

또 다른 대안은 Kubernetes에 컨테이너로 배포하는 것입니다. 이미 클러스터를 구성한 사람은 프레젠테이션을 추가 응용 프로그램으로 쉽게 배포할 수 있습니다. 다른 모든 사람에게 이 예제는 Jenkins 및 Kubernetes를 사용한 지속적 전달을 위한 최초의 간단한 샘플 애플리케이션 역할을 할 수 있습니다.

빌드가 이미 Jenkinsfile 정의된다, 그것은 떨어진다 Dockerfile (예: Docker 이미지의 청사진)은 다음에서 명확합니다.

FROM bitnami/nginx:1.14.2
COPY . /app/

여기에서 Nginx는 입증된 웹 서버로 사용됩니다(인터넷 트래픽의 거의 절반을 제공). 단, 공식 이미지는 기본 이미지로 사용하지 않고, bitnami, IT 보안을 전문으로 합니다. 공식 이미지와 달리 이것은 다음에서 사용됩니다. bitnami 아닌 root-사용자이므로 Kubernetes의 첫 번째 심각한 취약점(CVE-2019-5736)에 취약하지 않습니다.

에서 Dockerfile 그것은 주목해야한다 COPY . / 전체 작업 공간을 이미지에 복사한 다음 런타임에 Nginx에서 제공합니다. 이것도 예시가 되겠다 Jenkinsfile 그리고 k8s.yaml 사용 가능 – 보안 위험! 따라서 추가 .dockerignore 파일 유지:

  • ~로 시작하다 ** (다 무시)
  • 그런 다음 부정을 사용하여 원하는 파일과 폴더를 해제합니다.
  • 이것은 효과적으로 화이트리스트로 이어집니다.

Kubernetes의 이미지에서 외부에서 액세스할 수 있는 컨테이너를 시작하려면 다음도 필요합니다.

  • 배포(컨테이너를 실행하는 포드용 템플릿),
  • 서비스(잠재적으로 임시 포드에 대한 고정 엔드포인트(IP 주소/DNS 이름)) 및
  • 인그레스(들어오는 요청에 대한 서비스에 대한 호스트 이름 매핑) – 물론 여기에는 구성된 인그레스 컨트롤러(예: Træfik)가 필요합니다.

이들은 모두 k8s.yaml 파일에 정의되어 있습니다. 흥미로운 점은 자리 표시자가 배포에서 이미지 이름으로 사용된다는 것입니다. image: $IMAGE_NAME.이것은 이미지의 현재 버전을 등록하기 위해 파이프라인에서 사용됩니다.

String versionName = createVersion(mvn)
//...
stage('Deploy Kubernetes') {
    deployToKubernetes(versionName)
}

// ...
void deployToKubernetes(String versionName) {

    String imageName = "cloudogu/continuous-delivery-slides-example:${versionName}"
    def image = docker.build imageName
    docker.withRegistry('', 'hub.docker.com-cesmarvin') {
        image.push()
        image.push('latest')
    }

    withCredentials([file(CredentialsId: 'kubeconfig-oss-deployer', variable: 'kubeconfig')]) {

        withEnv(["IMAGE_NAME=$imageName"]) {

            kubernetesDeploy(
                    CredentialsType: 'KubeConfig',
                    kubeConfig: [path: kubeconfig],

                    configs: 'k8s.yaml',
                    enableConfigSubstitution: true
            )
        }
    }
}

에서 Jenkinsfile 이미지는 먼저 Jenkins 온보드 리소스로 빌드되고 레지스트리로 푸시됩니다(예: DockerHub). 완성된 이미지는 여기에서 볼 수 있습니다. 현재 버전 이름은 Docker 태그로 설정되며 latest. 후자는 필수는 아니지만 Docker 레지스트리의 모범 사례입니다. 필요한 사용자 계정은 Jenkins에서 다음과 같이 생성됩니다. Username with password– 자격 증명 및 ID 전달(예제에서 이것은 hub.docker.com-cesmarvin) 로 docker.withRegistry()-단계. 사용자 계정에는 Docker 레지스트리의 이미지에 대한 쓰기 권한이 필요합니다(예제에서 cloudogu/continuous-delivery-slides-example).

이제 Kubernetes 배포에 이미지 이름을 입력하고 이를 클러스터로 전송해야 합니다. 이 두 단계는 모두 kubernetDeploy()-Kubernetes Continuous Deploy Plugin에서 제공하는 단계입니다. 수단 enableConfigSubstitution 가 있는 모든 항목이 활성화됩니다. $VARIABLE YAML 파일의 구문은 Jenkins 파이프라인의 적절한 환경 변수로 대체됩니다(예제에서 IMAGE_NAME). 또한 클러스터로 자신을 인증해야 합니다. 여기에서 CLI 도구 kubectl 아는 사람 kubeconfig-파일로 사용 Secret file– 자격 증명은 Jenkins에 저장됩니다(ID가 있는 예에서 kubeconfig-oss-deployer).

Jenkins에서 Container Registry 및 Kubernetes에 대한 자격 증명을 생성하는 방법에 대한 자세한 내용은 Jenkins 파이프라인에 대한 기사 시리즈의 4부에서 확인할 수 있습니다.

그래서 하나는 몇 줄에 있습니다 Jenkinsfile– 코드는 Docker 이미지 구축 및 Kubernetes 배포와 같이 복잡해 보이는 주제를 자동화합니다.

결론

Cloudogu 생태계

Cloudogu 생태계의 장점을 확신하십시오. 사용 이젠 공짜 최신 DevOps 플랫폼.

플랫폼으로

이 기사 시리즈를 마무리하기 위해 이 부분에서는 Jenkins에서 Continuous Delivery Pipeline을 사용하여 공개.js 프레젠테이션을 배포하기 위한 대상 환경의 더 많은 예를 보여줍니다. 특히 Sonatype Nexus 및 Kubernetes에 배포하는 방법을 설명합니다.

브라우저 기반 프리젠테이션으로 제공되는 이점 외에도 웹 애플리케이션의 지속적인 제공을 구현하는 방법이 구체적으로 표시되어 있음을 알 수 있습니다. 이 문서에서는 애플리케이션 및 사용 가능한 인프라에 따라 프로덕션 시스템에도 사용할 수 있는 선택 항목을 제공합니다.

  • 엔터프라이즈 환경에서 내부적으로만 사용할 수 있는 정적 웹 사이트를 배포하려는 경우 여기에서 Nexus를 사용하기만 하면 됩니다.
  • 정적 콘텐츠가 공개될 수 있거나 공개되어야 하는 경우 GitHub 페이지에 배포하는 것이 좋습니다.
  • Kubernetes는 최고의 유연성을 제공합니다. 여기에서 내부 및 외부 모두에서 정적 또는 동적 콘텐츠를 호스팅할 수 있습니다. 그러나 클러스터 운영은 더 복잡합니다. 여기에서 더 자세히 알고 싶으시면 교육 영역에서 찾을 수 있습니다.

About admin

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다