Github 작업으로 클라우드 로컬 구축 패키지 만들기

지난 몇 달 동안 나는 CNB technology, 특히 pack와 PackIt library를 접촉해 왔다.전반적으로 말하면 이것은 매우 재미있고 공부하는 과정이다. 나는 여기에 누워 있지 않을 것이다. 학습 곡선은 로켓에 의해 추진되는 것 같지만 사실은 네 머리를 잡고 새로운 용어와concepts 학습을 둘러싸면 매우 간단하다는 것을 증명한다.과학기술계의 어떤 일도 마찬가지다.
일단 내가 어떻게 하는지, 왜 그런지 알게 되면 나는 이것을 포장하고 저것을 포장하기 시작한다. 곧 나는 내가 중복된 일을 하고 있다는 것을 알게 되었다. 이런 일들은 모두 자동화를 구걸하고 있다.BuildPack에 묶인 간단한 스크립트를 말합니다. 배포, 조직, 버전 제어, 그리고 CNB가 가져다 주는 모든 장점을 말합니다.
나는 내가 이 문제를 해결할 수 있도록 좀 더 일반적인 도구를 만드는 데 시간을 들이기로 결정했다.
일련의 명령을 포함하고 효과적인 구축 패키지로 전환하는 작은 것이 필요합니다.내 머릿속에서 나는 이 새 장난감의 형상과 형상, 그리고 이 동적 구축 패키지의 생성을 조율하기 위해 일련의 사건을 볼 수 있고 거의 만질 수 있다.

생각

이 과정을 설명하는 가장 간단한 방법은 아래 그림을 사용하는 것이다.

# From a working PackIt project, parametrize and map input commands 
# taken from a YML file
┌───────────────────────┐
│      Base file        │ 
└───────────────────────┘
          ▼
# Compile the modified project so once the build process kicks 
# https://buildpacks.io/docs/concepts/components/lifecycle/build/
# our buildpack executes one by one the **commands**
┌────────────────────────┐
│      Build.go          │ 
└────────────────────────┘
          ▼
# Pack it for distribution and release at will
┌────────────────────────┐
│    buildpack.cnb       │
└────────────────────────┘

화이트보드 타임

내가 먼저 한 것은 나 같은 일반 사용자가 명령 목록을 어떻게 정의하는지 볼 수 있도록 아주 간단한 정의를 기초하는 것이다.나는 YAML로 이 일을 하기로 결정했다.다음은 명령 파일의 모양입니다.

This isn't a Github Action file although I borrowed some of the key names (name and run)

laraboot-commander:
  commands:
    - name: Init
      run: |
        echo "Init 🔥"
        pwd
    - name: NoOps
      run: |
        echo "Hello 🗺️"
        ls -ltah
    - name: Install deps
      run: |
        echo "installing 🤖"

This list could as well be defined as a list of "strings" but I foresee probably as a next step eventually I'd like to be able to pass extra parameters, environment variables, etc. Just like Github allows it. So the final definition looks something like the one below.

// type Commander struct {
//  WorkingDir string `yaml:"directory"`
//  Commands   []struct {
//      Name string `yaml:"name"`
//      Run  string `yaml:"run"`
//  } `yaml:"commands"`
// }

그리고 Gh pov에서 구축 패키지를 만드는 데 어떤 입력을 받고 싶습니까?이 문제는 대답하기 쉽다.Pack cli에 익숙하기 때문에, 이름과 버전만 물어보기로 했습니다.

알아차리다

프로젝트의 범위에 대해 우리는 검측이 시종일관 발생하고 구축 패키지는 시종일관 구축 계획에 참여하는 것에 동의합니다.

짓다

GO에서 bash 명령이나 스크립트를 성실하게 실행하는 것이 가장 쉬울 수 있기 때문에 구축 부분은 매우 빠르다.그럼에도 불구하고, 나는 길에서 내가 계획에서 예견하지 못한 거리들을 발견했다.
예를 들어 이것:ERROR: failed to build: the launch, cache and build flags should be in the types table of /layers/xxx . 기본적으로, 만약에 우리가 하나의 템플릿에서 구축 패키지를 만들고 사용자가 그것을 위해 이름을 제공할 수 있도록 허락한다면, 구축 과정에서 반드시 제공하는 이름을 고려해야 한다.우리는 buildpack.toml 파일에서 직접 grab the name of a buildpack을 받아야 한다.
또한 내 위치(어떤 컨텍스트 또는 경로)와 런타임 실패 원인은 알 수 없습니다.

로컬

WSDL 및 ubuntu 로컬

Github 작업을 통해 동일한 재구매 계약을 원격으로 실행

Github 작업

을 사용하는 다른 저장소(사용자)
마지막으로, 나는 빠른 원형으로서, 그것은 실제로는 매우 잘 작동하고, 심지어는 더욱 강한 것일 수도 있다고 말할 수 있다.

사용법

알겠습니다. build pack을 만드는 Github 동작을 어떻게 사용합니까?네가 이렇게 묻는 것은 더할 나위 없이 간단하다.
우선 지휘관 파일을 만듭니다.여러 명령 또는 한 명령만 포함할 수 있습니다.

#commander.yml
laraboot-commander:
  commands:
    - name: Init
      run: |
        echo "Hello World"

내 워크플로우의 일부로서 다음 세 가지 작업을 수행합니다.

행동.패키지 cli 및 기타 util 도구를 설정합니다.관심 있는 경우 repo를 참조하십시오.

우리 지휘관 행동

setup-pack

# .github/workflows/worklfow.yml
      - uses: buildpacks/github-actions/[email protected]
        with:
          pack-version: 0.20.0

      - name: Gh action
        uses: laraboot-io/laraboot-commander/actions/commander@master
        with:
          name: my-buildpack
          version: 0.0.2
          file: commander.yml

      - name: Upload dist
        uses: actions/upload-artifact@v2
        with:
          name: dist
          path: dist

만일 모든 것이 정상이라면 상황은 이렇다.

    'create'  buildpack.toml
    'create'  bin/build
    'create'  bin/detect
Successfully created 'my-buildpack'
Successfully created package 'dist/my-buildpack.cnb'

그런 다음 워크플로우의 일부로 또는 다른 항목에서 다음과 같이 이 build pack을 사용할 수 있습니다.

mkdir -p app
pack build sample-app --path app --buildpack my-buildpack.cnb --builder cnbs/sample-builder:bionic

결론

사용자 정의 GitHub 작업으로 YML 파일에서buildpack을 만드는 방법을 알았지만, 다른 CI 실행 프로그램에 쉽게 복사할 수 있습니다.
앞으로 몇 년 동안 우리는 패키지 구축에 대한 정보를 점점 더 많이 들을 것이다.자동화와 지속적인 통합의 시대에 개발자와 운영자의 게임 규칙이 바뀌었다.이 글의 원본 코드는 사용할 수 있습니다 here
이제 어떡하지?

Developing a third party CLI action

Creating container images with Cloud Native Buildpacks using AWS CodeBuild and AWS CodePipeline