バックグラウンド
ゼロから構築したわけではありませんが、クラスター内のサーバーの書き換えを担当したため、特定の条件下で、リーダーからgitlabにウェアハウスを作成し、自分でコードを送信するように依頼されました。私はこれまでgitlabを使用したことがありません。前の会社は仕事にsvnを使用していたので、私にはすべてが不明です。私のプロジェクトはgolangで書かれています。
私の目的は、プロジェクトをミラーにパッケージ化する—>ミラーウェアハウスにアップロードする—> k8sにデプロイすることです。
最初に倉庫を建てる
gitlabにログイン-> [新しいプロジェクト]を選択すると、次のページに移動し、自分の状況に応じて入力します
ここで注意すべきことの1つは、プロジェクトを作成した後、readme.mdのアップロードを求めるなどのガイドラインが表示されることです。当初は許可がなかったので何もできません。許可が得られるまで倉庫を運営できます。
許可を得た後、まず倉庫を地元に引き寄せます
プロジェクトを入力し、cloneを選択してから、必要な方法を選択し、gitcloneを使用してウェアハウスをローカルにプルします。プルした後、git addを使用できます。—> git commit -m“ xxxx” —> git push originmasterを使用してウェアハウスに送信します。
注：通常、gitがコミットするときは、一部のファイルを無視する必要があります。プロジェクトディレクトリに.gitignoreを追加するだけです。
私が提出したファイルはおそらく次のとおりですが、そのうち2つだけを知る必要があります。Gitignoreは
、提出する必要のない一部のファイルを無視する
ために使用されます。Gitlab-ci.yamlは自動デプロイに使用されます。
最初にgitlabcicdについて説明します
実際、これは難しいことではなく、なぜインターネット上にこれほど多くの説明があるのかわかりません。私が書くことができないのは、初心者には理解しにくい概念の長いリストです。cicdには2つのものが必要です：.gitlab-ci.yamlファイル、gitlab-runner
.gitlab-ci.yaml
は、実際に必要な自動デプロイプロセスを記述します。たとえば、Dockerイメージをパッケージ化してアップロードする必要がある場合は、gitlab-ci、yamlでその構文を使用してこのプロセスを記述する必要があります。
gitlab-runnerの
方がわかりやすいです。インターネットでどんな説明があるのかわかりません。自動デプロイスクリプトを作成したので、作成した自動デプロイスクリプトを実行するための何かが必要です。これは、gitlab-runnerです（k8sのポッドと同様です。正しくない場合は、指摘してください）。
実際、これら2つは非常に単純なものですが、とにかく、私がそれらを理解した後、私はただそう言います。gitlab-runnerが実行される場所は、gitlabプロジェクトのアドレスです。つまり、作成するスクリプトは、プロジェクト用のフォルダーを持つLinuxマシンと同等であり、このフォルダーの下にスクリプトを作成します（これは私自身の理解であり、私はこれを行いました。何か問題がある場合は、それについて話し合ってください）、. gitlab-ci.yamlにスクリプトを記述し、ls、pwdコマンドを使用してUpを知ることができます。
展開フェーズ
.gitlab-ci.yamlファイルを書き込む
最初は知りませんでしたが、golangのcicdデモを直接使用しました（cicdをgitlabに追加する必要はなく、デモを選択できます）。実行後、実際には.gitlab-ci.yamlがシェルスクリプトとして書かれています（当時は知りませんでしたが、実際、これはgitlab-runnerに関連しています。後で説明します）。これは簡単です。
文法についてはここでは説明
しません。プロジェクトなので一部しか投稿できません。
脚本全体は3段階に分かれています。
stages:
- build
- docker_publish
- deploy
ビルドコードがアップロードされたら、たとえば私のファイルに直接ビルドするスクリプトを記述します
build:
image: golang:1.15.6
stage: build
before_script:
- mkdir -p $GOPATH/src/$(dirname $REPO_NAME)
- ln -svf $CI_PROJECT_DIR $GOPATH/src/$REPO_NAME
- cd $GOPATH/src/$REPO_NAME
script:
- pwd
- ls
- cd realTimeMsg
- go mod download
- go build -o $CI_PROJECT_DIR/RtmServer
artifacts:
paths:
- RtmServer
expire_in: 2 mos
これは非常に理解しやすく、主にスクリプトを見ると、一目でわかります。
docker_pulishは、出力をミラーにパッケージ化します。これには、dockerをdockerで使用する必要があり、サービスは次のとおりです。
このビルドは難しくありません。gitlabで作成したDockerfileをアップロードして、直接ビルドしてください。
docker_publish:
image: docker:latest
services:
- docker:dind
script:
...
- docker build -f Dockerfile --pull -t xxx
- docker image ls
- docker push xxx
ここで注意を払う必要があります。.gitlab-ci.yamlファイルでは、定義する必要のある環境変数を設定-> cicdで設定できます。
デプロイ展開、私が遭遇した最大の問題はここにあります
デプロイスクリプトでは、dev k8sにデプロイできません。スクリプトkubectlcluster-infoを使用しましたが、スクリプトが実行されている場所がdev k8sではないため、確実にデプロイできません。この場合、私はチェックに行きました。
この問題の理由は次のとおりです。gitlab-runnerが必要な環境で実行されません。したがって、クラスターに関連付けることはできません。
プロジェクトをデプロイしたとき、gitlab-runnerを作成しませんでしたが、デプロイメントスクリプトは実行されました。
問い合わせたところ、参加したプロジェクトにはデフォルトの共有gitlab-runnerがあることがわかったので、これを直接実行しました。
最初にプロジェクトをk8s（このボタン）に追加しようとしましたが、追加されたことが判明しました。追加した後、これになりました。
追加の方法は次のとおりです：https：//segmentfault.com/a/1190000020947651、この記事を参照します。
しかし、それは私の問題を解決しませんでした。
最後に、devのk8s環境でプロジェクトのgitlab-runnerを登録しました。開発環境はすでにgitlab-runnerに存在します。存在しない場合は、インストールするだけです。
その後、最初に
設定- > cicd-> runnersを開き、次にgitlab-runner registerを使用し
て
前のランナーイメージのURLを入力します。前のランナーイメージのトークン
エントリと終了の説明を
入力します。タグを入力します。これは非常に重要です、.gitlab-ci.yamlスクリプトタグに関連付けられたランナー
入力選択の実行方法を通じて、シェルを選択しました
登録後、設定-> cicd-> runnersにはもう1つのランナーが
あり、タグが.gitlab-ci.yamlファイルに関連付けられている場合でも、ここでは使用できないことがわかります。そのような関連付け、タグを追加します
deploy:
image: dtzar/helm-kubectl:2.9.1
stage: deploy
tags:
- goRtm
このランナーは走れないので、走れると正面が緑色になり、タグが変更されています。上の写真の対応するランナーとは異なります。説明してください。
また、gitlab-runner runを呼び出す必要があります。呼び出し後、緑色になり、使用できるようになります。
これが完了すると、コードを送信した後、必要なk8に自動的にデプロイできます。
記事には会社のプロジェクトが含まれているため、多くのことを明確に説明することはできません。おそらくこのようにしか書けません。