gitlabのgitlab-runner自動配置

5088 ワード
ツール
転載先:https://blog.csdn.net/hxpjava1/article/details/78514999

概要


gitlab-ciの全称はgitlab continuous integrationの意味であり、すなわち持続的な統合である.中心的な考え方は、gitlabにpushが届くたびに、スクリプトの実行がトリガーされ、スクリプトの内容にはテスト、コンパイル、導入などのカスタムコンテンツが含まれます.本稿ではgitlab-ciの持続的な統合を用いて自動導入を実現する.これまでのwebhookの自動導入に比べて、強力で便利です.

げんり


自動導入にはいくつかの役割があります.主に次のように説明します.
  • GitLab-CIこれはGitLabに合わせて使用される持続的な統合システムで、GitLabが持参したものです.つまり、GitLabをインストールしたサーバーに搭載されています.あまり考えなくてもいいです.gitlab-ci.ymlのスクリプト解析はそれが担当します.
  • GitLab-Runnerこれはスクリプト実行のベアラである.gitlab-ci.ymlのscript部分の実行はrunnerが担当しています.GitLab-CIはプロジェクトをブラウズしたことがある.gitlab-ci.ymlファイルの後、中のルールに従って、各Runnerに割り当てて、対応するスクリプトscriptを実行します.これらのスクリプトには、テストプロジェクト用のものもあれば、導入用のものもあります.GitLab-CIとGitLab-Runnerの関係概略図
  • .gitlab-ci.yml gitプロジェクトのルートディレクトリの下にあるファイルで、一連のフェーズと実行ルールが記録されています.GitLab-CIはpush後に解析し,その内容に基づいてrunnerを呼び出して実行する.

    • ステップ

  • インストールGitLab-CIこれはインストールする必要はありません.GitLabを装着すると
    • を持参します.
  • インストールGitLab-Runner centOSにgitlab-ci-multi-runnerをインストールgitlab-ci-multi-runnerをインストールします.しかし、gitlab-runnerをインストールしただけです.もちろんgitlab-CIにこのrunnerを登録します.そうしないと、gitlab-CIはpushイベントが来たときに誰を呼び出すか分かりません.ここでもwebhook方式との違いを見つけることができます.webhook方式はgitlabに接続するようにアクティブに構成されています.gitlab-runnerは登録すればいいです.では、登録して登録します.gitlabの対応する場所には、登録したrunner情報が表示されます.
  • $ curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash
  • $ yum install gitlab-ci-multi-runner
  • $ gitlab-ci-multi-runner register
  • # gitlab url， url， http://gitlab.example.com/
  • # token， token， ase12c235qazd32
  • # tag， runner， tag runner ， ， web,hook,deploy
  • # executor， ， shell 。

  • 作成.gitlab-ci.ymlはプロジェクトルートディレクトリの下で作成する.gitlab-ci.ymlはpushの後gitlab-ciが自動的に認識して解析する.
  • stages:
  - deploy
  - build
  - ops

deploy-web1_job:
  stage: deploy
  tags:
    - gitRunner tag 
  only:
    - master
  script:
    - bash deploy     master

build-web1_job:
  stage: build
  tags:
    - gitRunner tag 
  only:
    - master
  script:
    - source /etc/profile
    - cd /data/wwwroot/master/ / 
    - /data/wwwroot/apache-maven-3.6.0/bin/mvn clean package -Dmaven.test.skip=true

ops-web1_job:
  stage: ops
  tags:
    - gitRunner tag 
  only:
    - master
  script:
    - rm -f /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/ .war
    - cp /data/wwwroot/master/ / /target/ .war /data/wwwroot/tomcat/apache-tomcat-8.5.35/webapps/ .war
     
  • ここにはdeployというステージが1つしかありません.onlyは、masterブランチpushの場合にのみ実行されることを指定します.tagsはshellで、さっきrunnerに登録したときのtagsに対応しています.最も重要なscriptセクションdeploy Example_Group Example_Project、ここではshellコマンドです.汎用性を容易にするために、deployは私がサーバーで作成したスクリプトで、入力パラメータはExample_です.Group Example_Projectは、それぞれプロジェクトグループ名とプロジェクト名です.このコマンドを実行すると、/xxx/Example_に自動的に配置できます.Group/Example_Projectのサーバディレクトリの下にあります.では、どんなプロジェクトでもこのフォーマットでカバーすればいいので、新しいプロジェクトの自動配置もサーバにログインして修正する必要はありません.
  • deployスクリプトはgitlab-runnerの~/.local/bin/ディレクトリの下にdeployファイル
    • を新規作成
  • $ su gitlab-runner
  • $ mkdir ~/.local/bin
  • $ cd ~/.local/bin
  • $ touch deploy  
  • は、ディレクトリが存在しない場合はgit clone、存在する場合はgit pullの1つを指定ディレクトリの下に編集する
    if [ $# -ne 3 ]
then
      echo "arguments error!"
      exit 1
else
      deploy_path="/data/wwwroot/$3/$1/$2"
      if [ ! -d "$deploy_path" ]
      then
              git clone "gitlab :${1}/${2}.git" $deploy_path
	      cd $deploy_path
              git checkout $3
      else
              cd $deploy_path
              git pull
      fi
fi
    というスクリプトの大意である.これにより、自動導入の目的が達成されます.中のgitlabを修正してください.example.comのアドレスですよ.実行権限を付けてgitlab-runnerの~/.local/binで有効になります(見苦しい./deployを書かないように)
    $ chmod +x ~/.local/bin/deploy
    そして~/.local/binを$PATHパスに追加する(ユーザがコマンドを実行するときにこのディレクトリを見つけることができる).profile末尾にこの言葉
    PATH="$HOME/.local/bin:$PATH"
    • を加える
  • sshログイン上のdeployスクリプトを構成するには、gitlabにssh方式で連絡します.だからgitlab-runnerというユーザーにgitlab上でsshできるユーザーを構成します.まずgitlab-runnerの下で鍵対
    • を生成する.
  • $ mkdir ~/.ssh
  • $ cd ~/.ssh
  • $ ssh-keygen
  • #
  • $ cat id_rsa.pubはcatで公開鍵を表示し、この一連の公開鍵をコピーする.gitlabにgitlab-runnerというアカウントを新規作成し、このアカウントをプロジェクトメンバーに追加し、このアカウントのuser_profileの中に、公開鍵を貼り付けるといいです.つまりこのアカウントをsshでログインできるようにしています.
  • 配置ディレクトリ権限の移管スクリプトの実行に失敗したと主張する学生もいるかもしれませんが、/var/exampleの所有者がrootであり、gitlab-runnerは新しいファイルを作成する権限がないためです.だから私たちは/var/exampleディレクトリの所有者をgitlab-runner 
    $ chown -hR gitlab-runner:gitlab-runner /var/www
    に渡しました.もし成功しなかったら、サーバー上で手作業でdeploy XXを一度、このサーバーに初めてアクセスしたとき、signを既知のサーバーリストに追加するには、手作業でyesを入力する必要があるというコマンドラインのヒントがあります.サーバ上で正常なdeployがあれば、これで大成功です.
  • 注:発行実行中にsshの鍵検証がssh-keyscan-Hサーバip>~/.ssh/known_hosts

    • git pushを対応するプロジェクトに試して、サーバーのディレクトリに行って、あるかどうか見てみましょう.
    Linq NOT IN(またはNOT EXISTS)、LEFT JOIN踏み込み記
    【C言語シミュレーション実装】浮動小数点数-回転-定点数