継続的インテグレーションと展開は、DevOpsチームの重要な部分であり、ジェンキンスは、非常に人気の継続的な統合および展開ツールで、最近少しジェンキンスを実験し、私はそれはいくつかの時間の最も複雑なツールのために使用されることが判明。一つの可能な理由は、それが統合的なアプローチと異なる一方で、タスクを完了するために他のさまざまなツールと統合する必要があるということです。これらのツールでは、ドッカーは本当に使いやすい、最も簡単です。コンテキストを把握し、その後、中核となる概念を見つけるために一度、より複雑なK8Sは、精通してまでに時間がかかるようになったが、その全体的なデザインは非常に合理的である、それは非常に滑らかです。いくつかは、自分の推測を命じることができるように、標準化と統一され、そのコマンドの形式は、これは良いデザインは利益をもたらすです。。しかし、ときジェンキンスは、初めはよく一つのことで損失の観点に慣れていない人のために、いくつかの異なるアプローチが存在する結果として、常に後ろのパッチ適用では、設計されていないという印象を与えます。どこでも統一スタイル、事故が全体のシステムは非常に複雑で、無トリック見せること、ありませんが、もちろん、単にについて長い時間を尋ねました。それが最高ではないかもしれないが、それは自由ですが、それはあまりにも過酷ではありません。
様々な理由から、私はジェンキンスは、さまざまな問題が発生したインストール、と私は多くの情報を参照してください。ジェンキンスは多少異なりますインストールするには、どのように残念ながら誰もが、すべての問題を解決することができます記事を見つけることは困難です。私の意見では、二、三のキーポイントのジェンキンスのインストールは、間違いを犯すことは非常に簡単で、我々は徹底的に成功するために理解する必要があります。
この記事は、すべてがうまくいけば、第2の部分を参照する必要がない、二つの部分、通常は話すインストール手順の最初の部分に分かれています。私は、あなたにあなたの幸運をお祝いを言うことができます。第二部では、この問題をこの資料の最も貴重な一部である必要があり、問題と解決策についてです。
パートI：ジェンキンスK8Sに配備
1.任意の場所にインストールしますか？
容器はまた、ツールのコンテナに関連付けられていることを含む、アプリケーションの容器を含むだけでなく、傾向、です。自動的にタスクを完了するために、状況に応じて、子ノード（新しいコンテナ）が生成されますK8Sジェンキンス、ジェンキンスマスターノード上に展開すると、タスクは自動的に子ノードの後に破棄されます。
私は、最初の仮想マシンを管理するためにWindows仮想マシン上、およびベイグラントでVirtulBoxを展開して、仮想マシンK8Sに配備しました。それはホスト上で直接ツアーK8Sにジェンキンスがアクセスできるように、ネットワーク上の共有は、ベイグラント仮想マシンとホストとの間に設けられています。また、仮想マシンに問題がある場合でも、ジェンキンス、ジェンキンスは、または物理ホスト上に保存されたディスクをマウントするホストは、すべての設定とデータが失われます。
2.画像ファイルを選択
これは問題ではないようだが、油断しやすいがエラーに。私は間違ったイメージを選んだので、インストールを何度が得られ、この記事の第二部では、詳細な、最終的には成功しました。、以降の古いバージョンが、新しいイメージは「ジェンキンス/ジェンキンス：LTS」であることが判明した：私は、イメージファイルである「2.154-スリムjenkinsci /ジェンキンス」になってしまったが、それが正常にインストールされているように、何も引っ張るありません。ジェンキンスさんは本当に欺瞞、「ジェンキンス」右「はジェンキンス/ジェンキンス」である「jenkinsci /ジェンキンス」、「ジェンキンス/ジェンキンス」、3つのミラーがあります。
画像を選択したら、ローカル・ジェンキンス（仮想マシン）にイメージファイルをダウンロードするには、次のコマンドを実行することができます。
vagrant@ubuntu-xenial:~$ docker pull jenkinsci/jenkins:2.154-slim3.インストールジェンキンス画像：
インストールの前に、ホストは最初のジェンキンスさんがローカルに直接ジェンキンスを操作することができ、仮想マシンにマウントされたディレクトリをインストールする必要があります。
以下は、仮想マシンにホストコンピュータが「/ホーム/浮浪者/アプリ」のアプリのディレクトリをマウントするベイグラントプロファイル（Vagrantfile）が設けられています 。ジェンキンスさんは、appディレクトリにインストールされています。
config.vm.synced_folder "app/", "/home/vagrant/app", id: "app"ここでは良いジェンキンスディレクトリのホストにインストールされています
ジェンキンスインストールイメージを順番にする必要があり、永続的なボリューム、インストールの展開とインストールサービスをインストールするには、サービスアカウントを作成し、4つの部分に分かれています。キーは、サービスアカウントを作成することで、これは必見です、いや、それは成功しません。いくつかのオンライン記事はそれを言及しなかった理由を私は知りません。
サービスアカウントプロファイル（サービス-account.yaml）：
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: service-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["services"]
verbs: ["get", "watch", "list"]
- apiGroups: [""]
resources: ["pods"]
verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
resources: ["pods/exec"]
verbs: ["create","delete","get","list","patch","update","watch"]
- apiGroups: [""]
resources: ["pods/log"]
verbs: ["get","list","watch"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get"]
ここでは、特定のリソース（例えば、[「サービス」]）に割り当てられている（例えば、[「取得」、「時計」、「リスト」]）「ClusterRole」の「サービスリーダー」という名前のディレクトリを作成し、特定の許可。
クラスタ結合文字「サービス・リーダポッド」と呼ばれるファイルを作成するには、次のコマンドを実行し、その「clusterrole」は「サービスリーダー」で、その名は「デフォルト：デフォルト」、最初の「デフォルト」ネームスペース（名前空間）で、第二の「デフォルトは」この名前（デフォルト）を参照する展開構成ファイルに続いてサービスアカウント名、です。ここで私は、したがって、それはデフォルトの名前空間（「デフォルト」）を使用して、ジェンキンスのために別の名前空間を作成していなかったので。
kubectl create clusterrolebinding service-reader-pod --clusterrole=service-reader --serviceaccount=default:defaultサービスアカウントの権限の定義を参照してください「ジェンキンスためKubernetesプラグイン」。
ラスティングボリュームの設定ファイル（ジェンキンス-volumn.yaml）：
apiVersion: v1
kind: PersistentVolume
metadata:
name: k8sdemo-jenkins-pv
labels:
app: k8sdemo-jenkins
spec:
capacity:
storage: 1Gi
# volumeMode field requires BlockVolume Alpha feature gate to be enabled.
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
storageClassName: standard
local:
path: /home/vagrant/app/jenkins
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- minikube
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: k8sdemo-jenkins-pvclaim
labels:
app: k8sdemo-jenkins
spec:
accessModes:
- ReadWriteOnce
# storageClassName: local-storage
resources:
requests:
storage: 1Gi #1 GB展開設定ファイル（ジェンキンス-deployment.yaml）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: k8sdemo-jenkins-deployment
labels:
app: k8sdemo-jenkins
spec:
selector:
matchLabels:
app: k8sdemo-jenkins
strategy:
type: Recreate
template:
metadata:
labels:
app: k8sdemo-jenkins
spec:
serviceAccountName: default # 服务账户的名字是default
containers:
- image: jenkinsci/jenkins:2.154-slim
name: k8sdemo-jenkins-container
imagePullPolicy: Never
ports:
- containerPort: 8080
- containerPort: 50000
volumeMounts:
- name: k8sdemo-jenkins-persistentstorage
mountPath: /var/jenkins_home
volumes:
- name: k8sdemo-jenkins-persistentstorage
persistentVolumeClaim:
claimName: k8sdemo-jenkins-pvclaim
なお、ここで引用されたサービスアカウントの「デフォルト」（serviceAccountName：デフォルト）。
サービスプロファイル（ジェンキンス-service.yaml）：
apiVersion: v1
kind: Service
metadata:
name: k8sdemo-jenkins-service
labels:
app: k8sdemo-jenkins
spec:
type: NodePort
selector:
app: k8sdemo-jenkins
ports:
- port: 8080
name: http
protocol : TCP
nodePort: 30080
targetPort: 8080
- port: 50000
name: agent
protocol: TCP
targetPort: 50000
キーポイントは、サービスの展開とは、2つの容器ポートに露出されていることを1 8080があり、他方が「8080」50000外部アクセスジェンキンスのポートであり、「50000」のポートがジェンキンス間のクラスタ内の相互に通信であります。ここでは、ジェンキンスのクラスタを構築する必要はありませんが、これらの2つのポートが設定されている必要がありので、ジェンキンスは自動的に、必要性に基づいて生成されました。ここでは、コンフィギュレーションコマンドは、比較的標準的K8S構成であるため、詳細に説明しません。
あなたは（ベイグラント構成を含む）K8S注文の詳細をお知りになりたい場合は、を参照してください「：永続的なボリュームを持つネットワークのMySQLマスター（Kubernetes）重要な概念のK8S（上）を介して構築」。
ジェンキンスを作成するには、次のコマンドを実行します。
kubectl apply -f jenkins-volume.yaml
kubectl apply -f jenkins-deployment.yaml
kubectl apply -f jenkins-service.yamlインストールを確認します。
ポッドを得るジェンキンスの名前
vagrant@ubuntu-xenial:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 15 27d
k8sdemo-backend-deployment-6b99dc6b8c-tbl4v 1/1 Running 7 11d
k8sdemo-database-deployment-578fc88c88-mm6x8 1/1 Running 9 16d
k8sdemo-jenkins-deployment-675dd574cb-bt7rx 1/1 Running 2 24hジェンキンスログの表示
vagrant@ubuntu-xenial:~$ kubectl logs k8sdemo-jenkins-deployment-675dd574cb-bt7rx
Running from: /usr/share/jenkins/jenkins.war
webroot: EnvVars.masterEnvVars.get("JENKINS_HOME")
Nov 02, 2019 1:33:30 AM org.eclipse.jetty.util.log.Log initialized
INFO: Logging initialized @3749ms to org.eclipse.jetty.util.log.JavaUtilLog
。。。
INFO: Invalidating Kubernetes client: kubernetes null
Nov 02, 2019 1:35:50 AM hudson.WebAppMain$3 run
INFO: Jenkins is fully up and running
--> setting agent port for jnlp
--> setting agent port for jnlp... doneあなたは「INFO：ジェンキンスが完全に稼働している」を参照すると、それはジェンキンスがうまく実行されていることを意味し、ジェンキンス最初のスタートの最初は我慢して、いくつかの時間がかかります。
4.ログイン
すでに述べたように、あなたがホストと仮想マシンベイグラント間のネットワークアクセスを設定することができ、私の仮想マシンのアドレスは「192.168.50.4」で、「30080」は、サービスの外部アドレスNodePortジェンキンスで、あなたができるので、 「http://192.168.50.4:30080/」アクセスジェンキンスと。
あなたは、ユーザーの初期ジェンキンスさんに管理者パスワードを取得することができます前に、まず最初のログインパスワードを取得する必要がありますディレクトリ「秘密initialAdminPasswordを\」、私はジェンキンスは、ホストディレクトリ「E：\ APP2 \ KUB \アプリ\ジェンキンス」でマウントので、と"：\ APP2 \ KUB \アプリ\ジェンキンス\秘密initialAdminPasswordを\ E" は、パスワード・ファイルがあります。パスワードは「072d7157c090479195e0acaa97bc1049」です。初めてログインしたら、ユーザー名とパスワードをリセットする必要があります。
5.推奨プラグインをインストールします。
ログイン後、最初のインストールを完了するために必要なプラグインをインストールし、直接選挙はそれに「プラグインを示唆したインストール」。
6インストールKubernetesプラグイン
ジェンキンスメインページ管理者アカウントでログインした後、見つけ
Jenkins-は、利用可能な「Plugins-を管理する」インストール「Kubernetesプラグイン」を選択することができ管理します。
この図は、インストール後の図です。
7.設定Kubernetesプラグイン
管理者アカウントでジェンキンスMasterメインページにログイン後、見つける
Jenkins-「設定システム- 」を管理して、Kubernetesプラグインを設定します。下図のように：
これは、インストール全体の成否を決定する、最も重要な構成です。デフォルトの「名前」は「Kubernetes」で、これは修正される必要があり、それ以降のパイプラインを構成するために使用されません。その上： "//kubernetes.default https" を持つ "Kubernetes URL"。「テスト接続」をクリックして設定した後、「接続テストに成功」の成功を参照してください。
「ジェンキンスURL」ジェンキンスは、アドレス（仮想マシンの代わりに、ホストからの）外部からアクセス可能です。
あなたは「ジェンキンスのURL」のKubernetesを検索するには、次のコマンドを使用することができます。
vagrant@ubuntu-xenial:~$ sudo minikube service k8sdemo-jenkins-service --url
http://10.0.2.15:30080
http://10.0.2.15:32289もう一つの引数は、オンラインで多くの記事を言及しなかった。このパラメータはジェンキンスの異なるバージョンであってもよく、ある「ジェンキンストンネル」は、このパラメータを設定する必要がありますジェンキンスマスターとジェンキンススレーブ間の通信であるが、なぜ知らない、いくつかのバージョンではないかもしれませんそれは必要です。
ビューコンテナ名
vagrant@ubuntu-xenial:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d15e30169568 f793ea0abe00 "/sbin/tini -- /usr/…" 15 minutes ago Up 15 minutes k8s_k8sdemo-jenkins-container_k8sdemo-jenkins-deployment-675dd574cb-2thn2_default_fb10e438-0231-4fd2-8dbd-d9e2f0bb9d09_0ビューコンテナ住所：
vagrant@ubuntu-xenial:~$ docker inspect d15e |grep _8080
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_ADDR=10.100.3.79",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP=tcp://10.100.3.79:8080",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PROTO=tcp",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PORT=8080",上記の情報によると、ジェンキンスさんのアドレスは、「TCP：//10.100.3.79：8080」で、8080はそれに50,000を取り替えました。最終結果は、「HTTP」を追加しないように注意してください「10.100.3.79:50000」です。
8.試験ジェンキンス。
ジェンキンスさんは今、すべて以下のテスト、インストールされています。ジェンキンスでは、「新しい項目」のメインページをクリックして、以下に示すように、新しいプロジェクトを作成するプロジェクト名を入力し、「パイプライン」を選択します。
以下に示すように、プロジェクトの設定ページに、スクリプトファイルはjenkinsfile-テストです：
これは、直接ジェンキンスマスターノード（マスターノード名がマスターである）ので、基本的に何の問題がないだろう、プロモーターのノードを必要としない最も簡単なテストです。
ジェンキンスで選択した項目の「テスト」のメインページは、その後、選択したプロジェクトを実行するために「今のビルド」、および次のように「コンソール出力は、」結果を表示します：
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeRunning on Jenkins in /var/jenkins_home/workspace/test
[Pipeline] {[Pipeline] stage[Pipeline] { (Run shell)[Pipeline] sh+ echo hello world.
hello world.
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // podTemplate
[Pipeline] End of Pipeline
Finished: SUCCESS
9.テスト子ノード：
これは、もう少し複雑なテストは、あなたがこれは本当にインストールの成功または失敗を検出することができ、子ノードを開始する必要があります。新しいプロジェクト「スレーブ・テスト」を作成します。
def POD_LABEL = "testpod-${UUID.randomUUID().toString()}"
podTemplate(label: POD_LABEL, cloud: 'kubernetes', containers: [
containerTemplate(name: 'build', image: 'jfeng45/k8sdemo-backend:1.0', ttyEnabled: true, command: 'cat'),
containerTemplate(name: 'run', image: 'jfeng45/k8sdemo-backend:1.0', ttyEnabled: true, command: 'cat')
]) {
node(POD_LABEL) {
stage('build a go project') {
container('build') {
stage('Build a go project') {
sh 'echo hello'
}
}
}
stage('Run a Golang project') {
container('run') {
stage('Run a Go project') {
sh '/root/main.exe'
}
}
}
}
}
上記スクリプト（ジェンキンス-軟膏検定）です。「POD_LABELは、」任意の名前（Kubernetes-プラグインバージョン1.17.0の後、システムは自動的に名前を付けられますが、以前に名前の独自のを必要とします）、可能な場合は、「クラウド： 『kubernetes』」前の「Kubernetesプラグイン」フェーズで定義されます試合。これは、2つの段階があり、1は「ビルド」で、もう一つは「実行」です。単純化のための2つのミラーが同じになるように設定ミラー（あなたが参照することができ、ステージの後ろにこのスクリプト）、の各段階の定義における「podTemplate」で。試験ので、最初のステージの出力は、「エコーハロー」、もう一つはミラー「jfeng45 / k8sdemo-バックエンド：1.0」であるMAIN.EXEプログラムです。
ジェンキンスで選択した項目「スレーブ・テスト」のメインページは、その後、選択したプロジェクトを実行するために「今のビルド」、および次のように「コンソール出力は、」結果を表示します：
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] node
Still waiting to schedule task
‘testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l’ is offline
Agent testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l is provisioned from template Kubernetes Pod Template
Agent specification [Kubernetes Pod Template] (testpod-f754a7a4-6883-4be0-ba4f-c693906041ae):
* [build] jfeng45/k8sdemo-backend:1.0
* [run] jfeng45/k8sdemo-backend:1.0
Running on testpod-f754a7a4-6883-4be0-ba4f-c693906041ae-fjwqs-kbb7l in /home/jenkins/workspace/slave-test
[Pipeline] {
[Pipeline] stage[Pipeline] { (build a go project)
[Pipeline] container[Pipeline] {
[Pipeline] stage
[Pipeline] { (Build a go project)[Pipeline] sh
+ echo heollo
heollo
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // container
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Run a Golang project)[Pipeline] container
[Pipeline] {[Pipeline] stage[Pipeline] { (Run a Go project)
[Pipeline] sh
+ /root/main.exe
time="2019-11-03T01:56:59Z" level=debug msg="connect to database "
time="2019-11-03T01:56:59Z" level=debug msg="dataSourceName::@tcp(:)/?charset=utf8"
time="2019-11-03T01:56:59Z" level=debug msg="FindAll()"
time="2019-11-03T01:56:59Z" level=debug msg="user registere failed:dial tcp :0: connect: connection refused"
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // container
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // podTemplate
[Pipeline] End of Pipeline
Finished: SUCCESS正常に実行され、テスト段階は完了です。
もともと二つの方法、「スクリプトPipleline」と「宣言Pipleline」で記述されたパイプラインの足、ここで最初の方法があります。詳細については、「参照Jenkinsfileを使用した。」「宣言Piplelineは」新しいアプローチで、私は今後の記事で話されます。ここにいるので、それは限り回線を介してテスト、です。
必要のないインストール手順：
一部のインストール手順は、いくつかの記事で述べたように、彼らはちょうどケーキの上のアイシングされ、必要ありません。ご使用の構成に問題がある場合、私はこれらのステップが原因で実行されていないことを疑いません。
- コンフィギュレーションのネームスペース（名前空間）：
いくつかのジェンキンスのインストール手順は、より良いので、当然のことながら、単一の名前空間を設定することですが、あなたは問題なく設定していない場合でも。 - Kubernetesサーバ証明書のキー：
一部のインストール手順は、「Kubernetesサーバ証明書キー」を設定する必要が言及したが、私はそれを設定し、また動作には影響を与えませんでした。
パートII：よくある質問
1.ジェンキンス誤ったバージョン：
下記に示すように、2.60.3-高山（これはすでにミラージェンキンスの最新バージョンである）あなたがプラグインをインストールするときに、このバージョンは、基本的には成功していない、低すぎる：ほとんどジェンキンスを使用して開始
その後ジェンキンスによって置き換え：最新、これはそれの日付である必要があり、結果は同じバージョンですが、LinuxはAplineではありません。
その後、最終的には、それは代わりにジェンキンスの、Jenkinsciを使用することです間違ってミラー化されて理解して（というよりも、問題のバージョン）になりました。すべてのプラグインでエラーが消えた上で、簡単ではありませんが、インストール後に、2.150.1-スリム：私はjenkinsci /ジェンキンスの最初の行で時間を過ごしました。
2. Kubernetesプラグインをサポートしていません。
しかしKubernetesプラグインはあまりにもピットである必要2.150.3を（私は2.150.1だった）、示唆、プラグインをインストールしたとき。私たちは、jenkinsci /ジェンキンスと、再び再ロードされるように、この時間を持っていた：2.154-スリム、幸いにも最終的には成功しました。しかし、この事実または前の画像、「ジェンキンス/ジェンキンス」の最新。
3. Kubernetesにアクセスできません。
次のエラーメッセージ：
Forbidden!Configured service account doesn't have access. Service account may have been revoked. User "system:serviceaccount:default:default" cannot get services in the namespace "default"詳細については、参照するAT「：serviceaccount：デフォルトデフォルトシステム」の名前空間にサービスを取得することはできませんKubernetesログ、ユーザーは。
エラーなし確立されたサービスアカウントが存在しないため。解決策は、「サービスaccount.yaml」ファイルを作成し、次のコマンドを実行することです。
kubectl create clusterrolebinding service-reader-pod --clusterrole=service-reader --serviceaccount=default:defaultもう一度実行して、エラーが表示されなくなります。
4.ジェンキンスのURLアドレスが間違っています
メインページジェンキンスでは、Jenkins-「システムログ - 」すべてのジェンキンスログ、次のエラーメッセージを管理します入力してください。
SEVERE: http://192.168.50.4:30080/ provided port:50000 is not reachable
java.io.IOException: http://192.168.50.4:30080/ provided port:50000 is not reachable
at org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.resolve(JnlpAgentEndpointResolver.java:303)
at hudson.remoting.Engine.innerRun(Engine.java:527)
at hudson.remoting.Engine.run(Engine.java:488)このエラーは、コンフィギュレーションとKubernetes・プラグインに主として関連しています。ジェンキンスではメインページ、Jenkins-「設定システム」の管理入力して、二つの「ジェンキンスURLは、」内部「http://192.168.50.4:30080/configure」で混同しないようにし、そこにあります。
最初はジェンキンスアドレスにアクセスするためのホストである「ジェンキンス場所」の下の「ジェンキンスURL」、です。
第二は、仮想マシンからアクセスジェンキンスアドレスである「クラウド」の下の「ジェンキンスURL」、です。
上の図では、私が最初に使用される「http://192.168.50.4:30080/」ですが、これは、URLのホストジェンキンスからアクセスされ、URLは、仮想マシン内からはアクセスできません。
あなたは「ジェンキンスのURL」のKubernetesを検索するには、次のコマンドを使用することができます
vagrant@ubuntu-xenial:~$ sudo minikube service k8sdemo-jenkins-service --url
http://10.0.2.15:30080
http://10.0.2.15:32289URLをテストするには、次のコマンドを入力します。
vagrant@ubuntu-xenial:~$ curl http://10.0.2.15:30080
<html><head><meta http-equiv='refresh' content='1;url=/login?from=%2F'/><script>window.location.replace('/login?from=%2F');</script></head><body style='background-color:white; color:white;'>
Authentication required
<!--
You are authenticated as: anonymous
Groups that you are in:
Permission you need to have (but didn't): hudson.model.Hudson.Read
... which is implied by: hudson.security.Permission.GenericRead
... which is implied by: hudson.model.Hudson.Administer
-->
</body></html> これは、URLが良い説明しています。
スレーブは接続できません
「ジェンキンスURLは」変更した後、アドレスはまだどこにも、正しいです。プロジェクトを実行すると、ページには、次の情報が表示されます。
（Jenkins->軟膏テスト中 - ＃はビルド＃13です>＃13、）「コンソール出力」は、以下の情報が表示されます。
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] node
Still waiting to schedule task
‘testpod-d56038a0-45a2-41d1-922d-2879e3610900-0hr0m-sfv8s’ is offlineその後充填する引数、つまり、「ジェンキンストンネル」があることがわかりました。図に示すように。
詳細については、奴隷常にオフライン- Kubernetesジェンキンスプラグインを。
元の情報に充填した後、この情報は、オリジナルではない、なくなっているが、「成功したエージェントの発見」もあります。しかし、新しいエラーがあります。
チェックシステムログは、Jenkins-「システムログ- 」すべてのジェンキンス管理]を選択しジェンキンスメインページでは、この方法を使用することができますログを、 この情報は次のとおりです。
INFO: Agent discovery successful
Agent address: http://10.0.2.15
Agent port: 50000
Identity: 3e:1b:5f:48:f7:5b:f8:6d:ea:49:1d:b9:44:9a:2f:6c
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Handshaking
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connecting to http://10.0.2.15:50000
Oct 30, 2019 12:18:51 AM hudson.remoting.jnlp.Main$CuiListener error
SEVERE: null
java.nio.channels.UnresolvedAddressException
at sun.nio.ch.Net.checkAddress(Net.java:101)
at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:622)
at java.nio.channels.SocketChannel.open(SocketChannel.java:189)
at org.jenkinsci.remoting.engine.JnlpAgentEndpoint.open(JnlpAgentEndpoint.java:203)
at hudson.remoting.Engine.connectTcp(Engine.java:678)
at hudson.remoting.Engine.innerRun(Engine.java:556)
at hudson.remoting.Engine.run(Engine.java:488)それは、次のような方法は、「ジェンキンストンネル」アドレスを見つけるために使用することができるので、「JenkinsTunnel」アドレスまたは間違っています：
vagrant@ubuntu-xenial:~$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d15e30169568 f793ea0abe00 "/sbin/tini -- /usr/…" 15 minutes ago Up 15 minutes k8s_k8sdemo-jenkins-container_k8sdemo-jenkins-deployment-675dd574cb-2thn2_default_fb10e438-0231-4fd2-8dbd-d9e2f0bb9d09_0
vagrant@ubuntu-xenial:~$ docker inspect d15e |grep _8080
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_ADDR=10.100.3.79",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP=tcp://10.100.3.79:8080",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PROTO=tcp",
"K8SDEMO_JENKINS_SERVICE_PORT_8080_TCP_PORT=8080",上記の情報によると、ジェンキンス容器アドレスは「TCP：//10.100.3.79：8080」で、8080はそれに50,000を取り替えました。最終結果は、「HTTP」を追加しないように注意してください「10.100.3.79:50000」です。
詳細については、ジェンキンストンネルに使用する設定は何？
6.ミラー問題
使用して、画像ファイル場合は、「k8sdemo-バックエンド：最新」または「k8sdemo-バックエンド：1.0」、「コンソール出力」エラーが次のように：
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline[Pipeline] podTemplate[Pipeline] {[Pipeline] nodeStill waiting to schedule task
All nodes of label ‘testpod-2971e0ce-e023-475f-b0ec-6118c5699188’ are offline
Aborted by admin[Pipeline] // node
[Pipeline] }
[Pipeline] // podTemplate
[Pipeline] End of Pipeline
Finished: ABORTEDビューポッド、エラーが「ImagePullBackOff」です。
vagrant@ubuntu-xenial:~$ kubectl get pod
NAME READY STATUS RESTARTS AGE
envar-demo 1/1 Running 15 28d
k8sdemo-backend-deployment-6b99dc6b8c-tbl4v 1/1 Running 7 12d
k8sdemo-database-deployment-578fc88c88-mm6x8 1/1 Running 9 17d
k8sdemo-jenkins-deployment-675dd574cb-bt7rx 1/1 Running 2 2d
testpod-2971e0ce-e023-475f-b0ec-6118c5699188-xwwqq-vv59p 2/3 ImagePullBackOff 0 38sビューミラー：
vagrant@ubuntu-xenial:~$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
jfeng45/k8sdemo-backend 1.0 f48d362fdebf 11 days ago 14.4MB
k8sdemo-backend 1.0 f48d362fdebf 11 days ago 14.4MB
k8sdemo-backend latest f48d362fdebf 11 days ago 14.4MBここで彼らの「画像IDを」ミラーリング3「k8sdemo、バックエンド」の合計は、同じ理由で、私は次のコマンドで作成したので、3個のタグが存在する理由です
docker tag k8sdemo-backend jfeng45/k8sdemo-backend：1.0しかし、その後、彼は、唯一の「jfeng45 / k8sdemo-バックエンド：1.0」を作成した（最新の作成）パイプラインジェンキンススクリプトで使用することができ、他の二つが与えられています。成功し実行するための正しいイメージファイルを変更した後。
7. PVとPVC遅い削除
次のコマンドを使用して、PVを削除すると、復帰の遅れを命じます。
kubectl delete pv k8sdemo-jenkins-pvあなたは、状態（ステータス）を見ると、ディスプレイには「終了」となって、しかし、出口のない、常に終わりました。PVCは同じです。
vagrant@ubuntu-xenial:~$ kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
k8sdemo-backend-pv 1Gi RWO Retain Bound default/k8sdemo-backend-pvclaim standard 13d
k8sdemo-database-pv 1Gi RWO Retain Bound default/k8sdemo-database-pvclaim standard 18d
k8sdemo-jenkins-pv 1Gi RWO Retain Terminating default/k8sdemo-jenkins-pvclaim standard 6d8h主な理由は、そのサービスを利用することで、展開がまだサービスの最初の展開の後、実行して終了するとすぐに、PVとPVCの削除を削除され、正常に返さ。
出典：
記事0.1（タグ）下プログラムは、このプログラムのメインブランチが変更された後ことに留意されたいです。
以下は、プログラムのディレクトリ構造は、この記事のプロファイルの黄色の部分があります。
インデックス：
- ジェンキンスためKubernetesプラグイン
- （上）マスター（Kubernetes）によって構築されたMySQLの重要な概念のK8S：ネットワーク永続的なボリュームを持ちます
- Jenkinsfileを使用して
- Kubernetesはログイン、ユーザー「システム：serviceaccount：デフォルト：デフォルト」は、名前空間にサービスを取得することはできません
- Kubernetesジェンキンスプラグイン-奴隷常にオフライン。
- ジェンキンストンネルは何の設定を使用するには？
- ジェンキンスさんはKubernetesプラグインの継続的ビルドとリリースを使用して最初のテストを完了しました
ブログ記事複数のプラットフォームからこの記事OpenWriteリリース！