問題タブ [jenkins-docker]

ジェンキンスのバージョン: 1.643.2

Docker プラグインのバージョン: 0.16.0

私の Jenkins 環境には、2 ～ 5 個のスレーブ ノード サーバー (slave1、slave2、slave3) を持つ Jenkins マスターがあります。

これらの各スレーブは、Docker プラグインを使用して Jenkins グローバル構成で構成されます。

この時点ですべてが機能しています。

監視システムがスレーブ 3 で SWAP スペースの使用率が高い (例: IP: 11.22.33.44) というアラートをスローしているのを見たので、そのマシンに ssh して実行しました:sudo docker psこのスレーブ 3 で現在実行中の Docker コンテナーの有効な出力が得られました。機械。

ターゲット スレーブのマシン (4 つのコンテナーが実行ps -eo pmem,pcpu,vsize,pid,cmd | sort -k 1 -nr | head -10されている場所) で実行することにより、すべての RAM を消費している上位 5 つのプロセスがjava -jar slave.jar各コンテナー内で実行されていることがわかりました。だから、たわごとを再開して、記憶を取り戻してみませんか？次の出力では、ステップsudo docker ps前後のコマンドの状態を確認できます。docker restart <container_instance>右にスクロールすると、 で終わるコンテナー ID の 2 行目で、ホスト (slave3) マシン...0a02の仮想ポート (見出しNAMESの下にリストされている) が 1053 であることがわかります (これは、コンテナーの仮想 IP のポート 22 に SSH 用にマップされていました)。かっこいい、これが意味するのは、ジェンキンスからManage Nodeセクションでは、スレーブのコンテナーを再起動しようとすると、Jenkins は HOST IP の 11.22.33.44:1053 に接続しようとし、スレーブを正常に起動するために想定されていることをすべて実行します。つまり、Jenkins はその PORT (1053) をどこかに保持しています。

sudo docker restart <instanceIDofContainer>を実行した後、free -hRAM grep -i swap /proc/meminfo（以前は完全に使用され、残りの230MBの空き容量しか表示されていなかった）が1GBの空き容量であり、合計1GであったSWAPサイズが1G使用されました（swappiness 60または10の両方を試しました）が450MBになりました。空き領域をスワップします。そのため、アラートは解決されました。涼しい。

しかし、sudo docker ps上記の出力からわかるように、再起動ステップの後、そのコンテナー ID...0a02に対して、新しい PORT# 1054 を取得しました!!

[ノードの管理] > [このノードをオフラインにして停止し、再起動しようとした] に移動したとき、Jenkins は新しいポート (1054) を取得していません。どういうわけか古いポート 1053 を選択しています (ポート 1053 (コンテナーの仮想 IP のポート # 22 (ssh) にマップされている) で 11.22.33.44 (ホストの IP) への SSH 接続を試みている間)。

Jenkins が新しいポートを認識し、正常に再起動できるように、このスレーブ コンテナの Jenkins でこのポートまたは構成を変更するにはどうすればよいですか?

PS:ノードの[構成] をクリックしてその構成を確認しても、名前フィールド以外は何も表示されません。通常、通常のスレーブには多くのフィールドがあります (ラベル、ルート ディレクトリ、起動方法、プロパティ env 変数、スレーブ環境用のツールを定義できますが、これらの Docker コンテナーについては、単に名前フィールド）。Jenkins グローバル構成 ( Dockerプラグインのセクションの下) で[テスト接続] をクリックすると、Docker バージョン 1.8.3 が正常に検出されていることが示されます。

現在、1053 ポート (telnet) が機能していないため、このコンテナーのインスタンス ID が 1054 になったため (再起動ステップ後)、SSH 接続ステップ中に Jenkins の再起動ステップが失敗します (SSH メソッドを介して接続するために最初に行うこと)。