Docker デプロイメントサービスの落とし穴を登る過程の詳細

初めて書きます。自己紹介させてください...

みなさんこんにちは。私はジャスミンです。なぜジャスミンと呼ばれるのですか？えーっと、IDジャスミンがぐるぐる回ってるんですか？ 冗談だよ、へへ。著者は2年目の新人です（あと3日で2年目になります）。なぜなら、会社には私とフロントエンド開発者の2人しかいないからです。そのため、オンライン サービスの展開という仕事が自然に私の肩にかかってきました。実稼働環境でサービスをデプロイするために Docker が使用されるのは今回が初めてです。一つの穴から這い出て、別の穴に落ちる。この起動中に発生したバグを記録するだけです。私の書いた内容に間違いがあれば訂正してください。私を許して！ わかった。さっそく。アクション！

このプロジェクトでは、Spring Cloud、Spring Boot、Spring Gateway、MySQL を使用し、RatbitMQ も使用します。サーバーはcentos7です。 ここには大きな大釜が一つ欠けています。実は、私には3か月間一緒に働いているバックエンドの同僚がいます。この男性は、面接に行くための休暇申請を上司が承認しなかったため解雇されましたが、彼は結局面接に行きました。その枠組みを作ったのは彼です。えーっと、だから責任は私に押し付けられたんですね！

彼が使用したズールは私がゲートウェイに置き換えました。 Zuul はサーブレット 2.5 (3.x を使用) に基づいており、ブロッキング API を使用します。 Websocket などの永続的な接続はサポートされません。 Gateway は、Spring Framework 5、Project Reactor、Spring Boot 2 上に構築されており、非ブロッキング API を使用します。 Websocket がサポートされており、Spring と緊密に統合されているため、開発エクスペリエンスが大幅に向上します。

Docker イメージ サービスは、Alibaba Cloud のコンテナ イメージ サービスを使用します。同僚に聞いたところ、Google のコンテナ ツール jib を使用しているとのことでした。そこで、Cmd + Shift + F を押して、jib をグローバルに検索しました。 （すみません、これは中隊の規律なので騎兵の規律です⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄）

クリックしてご覧ください

Alibaba Cloud に入り、コンテナ イメージ サービスを探します (イメージ ウェアハウスがパーティション分割されていることを知らず、権限がないためウェアハウスを見つけられなかったため、ここでは手順を省略しました。その後、恥ずかしげもなく管理者アカウントを要求し、退職した同僚の従業員アカウントを変更しましたが、それでもウェアハウスを見つけることができませんでした)

次に、名前空間 xxx-prod を作成し、このスペースの下に各サービスのウェアハウスとプライベート ウェアハウスを構築しました。コード ソースについては、ローカル リポジトリをミラー リポジトリにプッシュすることを選択しました。他の人についてはあまり知りません。

(後でビルドする必要がなかったことが分かりました。jib 送信すると自動的にリポジトリが作成されます。手動で作成するときに選択しました。) jib を使用して送信した後、リポジトリのバージョン情報で更新を確認できます。

次にサーバーに接続します。ホームフォルダの下にdockerフォルダを作成する

//ルートディレクトリ内//~]# CentOS7でemmmと言う方法は、GitBashとOSシステムでは$、Windowsではcmdです>
//home の下に docker フォルダを作成します~]# mkdir /home/docker
//作成したドッカーに入る
~]# cd /home/docker

次に、Alibaba Cloud にアップロードしたイメージの取得を開始します。実はどのディレクトリでもプルできます（初めてAlibaba Image Serviceをプルしたときは省略しました。操作ガイドを読んでいませんでした。自分のアカウントに権限がないのではないかと疑いましたが、ログインしませんでした。その後dockerログインを維持しましたが、最後にAlibaba Cloudのイメージアドレスを追加する必要があることを知りませんでした：registry.cn-hangzhou.aliyuncs.com）Alibaba Cloudのイメージサービス管理コンソールで、任意のイメージリポジトリ->管理をクリックすると、イメージリポジトリの操作ガイドが表示されます。

イメージを取得したら、次のように入力します。

~]# Docker イメージ

先ほど取得した画像が表示されます。

同僚になぜここに鏡がたくさんあるのか尋ねたところ、彼はこう説明してくれた。

うーん、いいよ！メモリを占有する画像がたくさんあるといつも感じます（詳しい方がいらっしゃいましたらアドバイスを頂ければ幸いです）

ユーレカを始める

~]# docker run -d --name eureka -p 8761:8761 -p 15672:15672 -p 9001:9001 -v /etc/localtime:/etc/localtime registry.cn-hangzhou.aliyuncs.com/xx_xxx_prod/eureka
// -d バックグラウンド実行 -p バインドポート ここで 3 つのポートをバインドします。1 つは登録センター自体のポート、1 つはゲートウェイのポート、もう 1 つは rabbitmq のポートです //-v バージョン情報を出力します

rabbitmq が使用されるため、別の rabbitmq コンテナを作成する必要があります。 または、まずイメージをプルします

// イメージを取得するときは、最後のバージョンではなく管理バージョンを取得する必要があることに注意してください。管理バージョンには管理インターフェイスがあります。
~]# docker pull rabbitmq:management
~]# docker run -d --name rabbit -e RABBITMQ_DEFAULT_USER=xxx -e RABBITMQ_DEFAULT_PASS=xxx --network=container:eureka rabbitmq:management
//Docker コンテナはネットワークによって分離されているため、ネットワークは eureka と同じネットワーク環境に追加され、eureka ガバナンス下のサービスからアクセスできるようになります。
//-e は、コマンド内の xxx であるデフォルトのアカウント パスワードを設定します。これを使用する友人は、自分で調整できます。

独自のサービスを開始しましょう

~]# docker run -d --name xxx -v /home/docker/web-prod/logs:/logs -v /etc/localtime:/etc/localtime --network=container:eureka registry.cn-hangzhou.aliyuncs.com/xx_xxx_prod/xxx 
//-v は、指定したディレクトリにログをマウントします。 同様に、--network は eureka ネットワークに参加しますが、ここでポートをバインドする必要はありません。
//起動後、登録センターのコンソールでサービスの状態を確認できます。 ip + eureka のポート。

このようにサービスが実行されています。その他のサービス手順も同様です。最後に、私がオンライン上で遭遇した小さなエピソードをいくつか付け加えておきたいと思います。 最初は、docker コンテナがネットワークで分離されていることを知らず、--network を使用して eureka ネットワークを設定したことがなかったため、rabbitmq に接続できませんでした。したがって、サービス内の localhost から rabbitmq にアクセスすることはできません。また、サービスでrabbitmq遅延キューを使用する場合は、遅延キュープラグインをインストールする必要があります。 プラグインのインストール手順

ダウンロードするには公式ウェブサイトを開いてください: http://www.rabbitmq.com/community-plugins.html
対応するバージョン「3.7.x」を選択し、「ダウンロード」をクリックします。
~]# docker cp /home/docker/rabbitmq_delayed_message_exchange-20171201-3.7.x.ez rabbit:/plugins
//docker に入る~]# docker exec -it rabbit /bin/bash
//プラグインを開き、rabbitmq-plugins enable rabbitmq_delayed_message_exchange
//インストールされているすべてのプラグインを表示する rabbitmq-plugins リスト

図に示すように、インストールは成功しました。

docker rm がコンテナを削除すると、突然削除できなくなります。 docker ps -a でコンテナのステータスが Dead であることがわかりました。強制削除、マウント状態の確認、フォルダーの手動削除、ポート占有状況の確認など、オンラインで多くの情報を調べました。ほとんどすべてを試しましたが、効果はありませんでした。

最後に、おそらく経験から、何らかの方法で nginx と httpd の両方をオフにしてから削除しました。 なぜ nginx と httpd を同じサーバーにインストールしたのかは聞かないでください。このプロジェクトはもともと彼らが展開した PHP プロジェクトでした。私が引き継いだ後、私は自分で nginx を使用しました。

もう一つ非常に奇妙な問題があります。解決しましたが、なぜそれが起こったのかまだよくわかりません。ユーザーテーブルには last_password_reset_date があります。ユーザーがログインすると、この時間フィールドがチェックされ、トークンは常に無効として報告されます。各フィールドのログを入力すると、このフィールドはデータベース内の時間と 10 時間異なっていることがわかりました。当時は、タイムゾーンの問題だと思いました。ただし、同じテーブル内の別の register_date フィールドの時刻は正常であるため、タイムゾーンは処理されません。長い調査の後、Java が受け入れる時間型が間違っているか、同僚がこのフィールドを処理したのではないかと思いました。まだ修正されていません。その後、オンライン環境にテストライブラリを追加したところ、再び正常になったことがわかりました。最後に、テスト環境データベースのタイムゾーンを確認したところ、GMT+8 でした。オンライン ライブラリはデフォルトの GTM です。最後に、公式データベースの時間を東第 8 地区に変更します。

もう 1 つは Redis です。これは、以前に Redis を使用するパブリック アカウント サービスがあり、その時点では Redis サービスがホスト マシン上に存在していたためです。そこで、サーバーホストに接続しようと思ったのですが、最初は接続できませんでした。その後、redis 構成ファイルを変更し、bind パラメータをイントラネット IP にバインドしました。次に、イントラネット IP を使用してプログラム内の Redis に接続します。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。