Github Actions는 좋다.

왜 지금까지 사용하지 않았습니까?

GitHub Actions를 사용하기 시작했습니다.



지금까지 CodeCommit을 사용하여 리소스 관리를 하고 있었습니다만, 멤버로부터 풀릭 보기 어렵다고 불평이 있었으므로, CodeCommit에서 GitHub로 환승했습니다.
그 과정에서 소소하게 하고 있던 개발 기반이나 릴리스 기반의 정비를 하고 있습니다만, 그 중에서 수동으로 배포하는 것은 귀찮네요, 라고 하는 이야기가 되어, 모처럼이므로 자동 배포를 도입하게 되어, 그 안에서 사용하는 후보에 오른 것이 GitHub Actions입니다.

GitHub Actions의 지견은 거의 없었습니다만, 착수하고 나서 1~2시간 정도로 자동 배포의 Action을 할 수 있었으므로, 여기에서 여러분에게 그 장점을 소개하려고 생각합니다.

GitHub Actions의 편리함



실제로 사용해 보고 특히 편리하다고 생각한 특징이 이하입니다.
  • job이 YAML로 쓸 수 있습니다
  • 기본적으로 GitHub와 함께 작동할 수 있습니다
  • GitHub에서 제공하는 가상 시스템에서 실행
  • secrets를 사용할 수 있습니다

  • job이 yaml로 쓸 수 있습니다.



    YAML LOVE의 나에게 이것은 기쁘다.
    GitHub Actions의 설정은 리포지토리 이하, .github/workflows 디렉토리에 YAML 파일을 두고, GitHub상의 리포지토리에 push 하는 것만으로 완결합니다.

    이하, 할로와

    github/workflows/sample.yml
    # This is a basic workflow to help you get started with Actions
    
    name: Deploy
    
    # Controls when the action will run. Triggers the workflow on push or pull request 
    # events but only for the master branch
    on:
      push:
        branches: [ develop ]
    
    # A workflow run is made up of one or more jobs that can run sequentially or in parallel
    jobs:
      # This workflow contains a single job called "build"
      sample-deploy:
        # The type of runner that the job will run on
        runs-on: ubuntu-latest
    
        # Steps represent a sequence of tasks that will be executed as part of the job
        steps:
        # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
        - uses: actions/checkout@v2
    
        # task
        - name: echo
          run: echo "Hello World"
    

    YAML을 어느 정도 들고 있는 사람은 직관적으로 태스크를 상상할 수 있는 것을 알 수 있을까 생각하고, 구문도 매우 알기 쉽고 좋다. 좋은.

    쉽게 GitHub와 연동 가능



    GitHub Actions를 사용하는 이상, 브랜치의 merge나 push를 계기로 하고 싶은 것이 대부분입니다만, 그 점을 GitHub Actions의 기술은 꽤 간이화되고 있습니다.

    github/workflows/sample.yml
    # developへのpushを契機に実行
    on:
      push:
        branches: [ develop ]
    
    # A workflow run is made up of one or more jobs that can run sequentially or in parallel
    jobs:
      # This workflow contains a single job called "build"
      sample-deploy:
        # The type of runner that the job will run on
        runs-on: ubuntu-latest
    
        # developブランチを$GITHUB_WORKSPACEにcheckout
        - uses: actions/checkout@v2
    

    git 명령이나 GitHub API를 써도 좋지만, 오래 쓰는 것보다 알기 쉽고 똑똑하네요.

    GitHub에서 제공하는 가상 머신에서 실행



    GitHub Actions가 실행되면 가상 머신이 하나 생성되고 그 위에 Actions가 실행됩니다.
    runs-on: ubuntu-latest 에서 Ubuntu 이미지가 사용되고 있음을 알 수 있습니다.
    따라서 Ubuntu에서 사용할 수 있는 명령을 사용하여 배포 준비 작업/배포 작업을 정의할 수 있습니다. tar도 scp도 대부분의 명령이 움직입니다. 인스턴스 준비는 필요 없음.
        # Archive
        - name: archive package
          run: tar zcvf sample.tgz sample/*
    

    현재 Windows/Ubuntu/MacOS를 사용할 수 있는 모양. 자세한 내용은 아래 URL의 runs-on 항목을 확인하십시오.
    htps : // 에 lp. 기주 b. 코 m / 자 / 아 c 치온 s / 레후 렌세 /

    Secrets를 사용할 수 있습니다.



    AWS 리소스에 액세스하고 싶은 SCP 또는 SSH 하고 싶은 것도 있을까 생각합니다.
    하지만, 비밀키나 DB의 접속 정보등을 포지토리에 넣는 것은 극형에 가치가 있으므로, 그 때에 사용하는 것이 리포지터리로 설정하는 Secrets입니다.
    말하자면, 리포지토리 환경 변수와 같은 것으로, 한 번 설정하면 값은 누구로부터도 들여다 볼 수 없게 되므로 매우 편리. 리포지토리의 설정에서 설정할 수 있습니다.



    그래서 GitHub Actions는 그 Secrets를 이용할 수 있습니다. 쓰는 방법의 예는 다음과 같습니다.
    ${{ secrets.(HOST_PASSWORD)}}
    

    SSH의 비밀 키도 Secrets에 써 두고, Actions 실행시에 id_rsa 파일에 출력해 사용하는, 어떤 일을 하는 방법도 있습니다.
    ※ 참고 : GitHub의 새로운 기능 "GitHub Actions"에서 시험 CI / CD
    run: echo "${{ secrets.SECRET_KEY }}" > id_rsa && chmod 600 id_rsa
    

    요약



    이러한 방식으로 GitHub의 리포지토리에 대한 액세스, 배포 작업 관리 및 실행 관리가 모두 GitHub에서 완료됩니다. CI/CD 환경을 만들고 싶었지만, Jenkins와 까다로운, 다른 사람은 돈이 든다고 생각하는 분에게는 추천입니다.

    일단, 프리 플랜은 실행 시간 2000분/월까지 무료인 것 같기 때문에 그런 무거운 처리가 아니면 견딜 수 있을까 생각합니다. 꼭 시도해보십시오.

    좋은 웹페이지 즐겨찾기