「マイクロサービスワンストップ」ベストガイド-解答編:SupervisorとGitlab-Runnerがついに併存

これは「マイクロサービスの一連」のプロジェクトの第2編で、昨日の第1編で述べたGitlab-RunnerとSupervisorを使用して、私たちのプロジェクトを導入したことと、導入中に発生した問題に基づいています.

イベント復元

昨日残された問題と今日発見されたばかりのBUGを引用して、私たちはGitlab-Runnerをプロジェクトの持続的な統合のツールとして使用して、Supervisorをサービス管理のツールとして使用して、一連のテストを経て、私たちは1つの問題を発見しました.
(1)なぜroot起動Gitlab-Runnerサービスはtask起動rootサービスではなく最新のGitlab-Runnerを取得できないのか.
(2)我々が新たに発見したBUGは、昨日はきちんとしたプログラムを実行していたのに、今日は一連の権限不足の問題が発生しています.WHY?

イベント分析

(1)非rootを使用しているのは、登録runnerの場合、および起動runnerの場合に非rootのユーザを使用しているconfigファイル、すなわちディレクトリ/home/user/.gitlab-runner/config.tomlであり、これまで-cを使用して非rootのユーザのプロファイルを参照していたことは疑いの余地がないが、我々は登録runnerのときも非rootのユーザを使用して登録していたことを忘れていたので、rootのユーザを使用してGitlab-Runnerを起動したとき、runnerは非rootのユーザによって登録され、タスクを受信できませんでした.(2)権限が足りなくて、どこでrootを使って作成したのか、私たちはアクセスできません.私たちは検索して、私たちがGitlab-Runnerを起動したとき、私たちは/etcディレクトリの下のいくつかのファイルを引用する必要があります.つまり、私たちの普通のユーザーは訪問する権限がありません.この問題の根源はここから来ているはずです.

問題解決

(1)我々は異なる数人の一般ユーザを作成し,それぞれのrunnerを登録し,それぞれのGitlab-Runnerサービスを起動することにより,テスト後,タスクは対応tagにしか送信できず,対応tagがバインドされたrunnerに対応して受信できることを発見した.私たちがGitlab-Runnerサービスを開始するときは、Supervisorプロファイルにuser=rootを作成するか、userを指定しないか、デフォルトでrootユーザーで実行する必要があります.

総括は私达の2日间の绝えない振り回しGitlab-RunnerとSupervisorを経て、私达は最后に両者を结び付けて使う最良の方法Gitlab-Runnerを総括してrootユーザーで実行して、命令を実行するのはgitlab run -c config -u userで、このように私达はまた完全な権限があることを保证することができて、またrunnerの権限が最も低くて、両方が美しいことを保证することができます.