Dockerを使用する方法、またはDockerを使用しないよりも使用する方が良い理由

この記事は、Dockerについて既に知っている人、Dockerの目的を知っている人を対象としています。 しかし、彼は次に何をすべきかわかりません。 この記事は本質的に助言であり、「ベストプラクティス」のタイトルを侵害するものではありません。



したがって、おそらくdockerチュートリアルを読んだかもしれませんが、dockerはシンプルで便利なように見えますが、プロジェクトでどのように役立つかはまだわかりません。



通常、展開には3つの問題があります。

1. サーバーにコードを配信するにはどうすればよいですか？
2. サーバーでコードを実行するにはどうすればよいですか？
3. コードを開始して実行する環境と同じ環境を確保するにはどうすればよいですか？

Dockerが猫の下でこれをどのように支援するか。 それでは、Dockerではなく、Dockerなしでの生活から始めましょう。

サーバーにコードを配信するにはどうすればよいですか？

最初に思い浮かぶのは、すべてをパッケージに詰めることです。 RPMまたはDEBは関係ありません。

パッケージ

システムには、ファイルを管理できるバッチマネージャーが既にあります。通常は、次のものが必要です。

• 一部のストレージからプロジェクトファイルをサーバーに配信する
• 依存関係を満たす（ライブラリ、インタープリターなど）
• 以前のバージョンのファイルを削除し、現在のファイルを配信します。

実際には、今のところ動作します...状況を想像してください。 あなたは継続的にDevOpsです。 つまり 管理者が関与する日常的な活動の自動化に1日費やします。 ディストリビューションから動物園を飼育していない小さな車両群があります。 たとえば、Centosが大好きです。 彼女はどこにでもいます。 しかし、ここで問題が生じます。プロジェクトの1つをlibxxに置き換えるには、libyy（Centosの下にあります）を置き換える必要があります。 交換する理由-あなたは知りません。 ほとんどの場合、開発者はlibxxに対してのみ「いつものようにkrivoruky」を作成し、libyyでは機能しません。 さて、vimを手に入れて、libxxのrpmspecを記述します。これは、アセンブリに必要なライブラリの新しいバージョンについて並行して記述します。 約2〜3日間の運動で、結果は次のとおりです。

1. libxxが実行され、すべてが正常で、タスクが完了しました
2. libxxがビルドされなかったのは、たとえば、システムにlibyyがインストールされているため、削除する必要があるためですが、サーバー上の他の何かがそれに依存しているためです
3. libxxは構築されていません。他のライブラリと競合するライブラリが十分にありません

タスクに対処する確率の合計は約30％です（ただし、実際にはオプション2または3は常にドロップアウトします）。 そして、2番目の状況がまだ何らかの方法で処理できる場合（仮想マシンが存在するかlxc）、3番目の状況はあなたの動物園に別の獣を追加するか、ハンドル付きで/ usr / localにnull / slakvariの挨拶を収集します



一般的に、この状況は依存性地獄と呼ばれます。 これには、単純なchrootからNixOsのような複雑なプロジェクトまで、 数多くのソリューションがあります。





なぜ私はこれをしていますか。 そうそう。 パッケージ内のすべてを収集し、同じシステム上でそれらを駆動し始めるとすぐに、間違いなく依存関係の地獄の状況になります。 さまざまな方法で解決できます。 各プロジェクトに新しいリポジトリと新しい仮想マシン/ハードウェアを追加するか、制限を導入します。 制限とは、次のような企業ポリシーの特定のセットを意味します。「ここにはlibyy-vN.Nしかありません。 気に入らない人は誰でも声明で人事部に連絡してください。」 私はNNについてだけ言ったのではなく、いくつかのライブラリは2つのバージョンで同じサーバー上に存在できません。 制限は最終的に何も与えません。 ビジネス、そして常識はすぐにそれらすべてを破壊します。



より重要なことは自分で考えてください：サードパーティのコンポーネントの更新に依存する製品の機能を作成するか、環境の異質性を楽しむための時間を与えることです。

GITを介して展開する

通訳言語に適しています。 コンパイルする必要があるものには適していません。 また、dependency-hellを削除しないでください。

サーバーでコードを実行するにはどうすればよいですか？

この質問のために、daemontools、runit、supervisorのような多くのものが発明されました。 この質問には少なくとも1つの正解があると考えています。

コードを開始して実行する環境と同じ環境を確保するにはどうすればよいですか？

ありふれた状況を想像してください。あなたはまだ同じDevOpsであり、タスクはあなたにやって来ます。「Eniac」プロジェクト（プロジェクトの名前ジェネレーターから取得されます）をNサーバーにデプロイする必要があります。



EniacをGITからドラッグすると、既知の技術（Django / RoR / Go / 1C ）が使用され、通常の方法で収集され、起動されます...動作しません。 開発者に連絡して、最初の番号をhimって、いつものように「ライマン」であることを伝えます。 そして、彼はすべてあなたに戻ってきました、そして、あなたはすでに「krivoruk」です。 開発者にとってすべてが機能します。 上司の観点からは、プロジェクトを開始できません。 あなたです。 開発者のコ​​ンピューターにプロジェクトを展開したテスター以来、誰もが受け入れました。



問題を理解する。 先に進むと、1台のサーバーでEniacを実行できますが、それでもN-1では動作しません。

Dockerはどのように役立ちますか？

まず、最初に、プロジェクトをハードウェアに配信する手段としてDockerを使用する方法を理解しましょう。

プライベートDockerレジストリ

Dockerレジストリとは何ですか？ これは、debパッケージとそれらのメタデータファイルを配布するWEBサーバーのように、データを保存するものです。 Amazonの仮想マシンにDocker HubをインストールしてAmazon S3にデータを保存するか、インフラストラクチャにインストールしてCephまたはFSにデータを保存できます。



Dockerレジストリ自体は、dockerによって起動することもできます。 これは単なるPythonアプリケーションです（明らかに、多くのレジストリがサポートしているリポジトリ用のライブラリを作成することはできませんでした）。



そして、プロジェクトがこのリポジトリにどのように取り込まれるかを後で分析します。

サーバーでコードを実行するにはどうすればよいですか？

それでは、プロジェクトの配信方法を通常のパッケージマネージャーと比較してみましょう。 たとえば、apt：

apt-get update && apt-get install -y myuperproject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドは自動化に適しています。 彼女自身がすべてを静かに行います。アプリケーションを再起動する必要があります。



Dockerの例：

 docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1 superproject-run.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてそれだけです。 Dockerは192.168.1.1にあるdockerレジストリからダウンロードし、ポート80（ここにはnginxがあります）でリッスンします。これは、起動に必要なすべてのもので、イメージ内でsuperproject-run.shを実行します。



実行するイメージに2つのプログラムがあり、たとえば次のリリースでは、そのうちの1つがクラッシュした場合、他のプログラムはロールアウトする必要のある機能を入力した場合にどうなりますか。 問題ありません：

 docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.10 superproject-run.sh docker run -d 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1 broken-program.sh
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、私たちはすでに2つの異なるコンテナを持っています、そしてそれらの中にシステムファイルライブラリなどの完全に異なるバージョンがあるかもしれません。

コードを開始して実行する環境と同じ環境を確保するにはどうすればよいですか？

標準の仮想マシンまたは一般的な実際のシステムの場合、すべてを自分で行う必要があります。 まあ、シェフ/ Ansible / Puppetなどを勉強してください。 それ以外の場合、xxx-utilsがすべてのNサーバーで同じバージョンであるという保証はありません。



Dockerの場合、何もする必要はなく、同じ画像からコンテナを展開するだけです。

コンテナ組立

コードをdockerレジストリに取得するには（ユーザーまたはグローバルは関係ありません）、そこにプッシュする必要があります。



開発者にコンテナを自分で作成させることができます：

• 開発者がDockerfileを作成
• docker tag $ imageId 192.168.1.1:80/reponame/mysuperproject:1.0.5rc1
• そして、ドッカープッシュ192.168.1.1:80/reponame/mysuperproject:1.0.5rc1をプッシュします

または自動的に収集します。 コンテナを収集するものが見つからなかったので、 ここにはランパーと呼ばれる組み立てられた自転車があります



一番下の行は次のとおりです。

• サーバーに3つのコンポーネントlumperとRabbitMQをインストールします
• githubフックのポートをリッスンします。
• ランパーインストールのgithub web-hookで構成します
• 開発者はgit tag v0.0.1 && git push --tagsを作成します
• ビルド結果が記載されたメールを受け取る

Dockerfile

実際、複雑なことは何もありません。 たとえば、Dockerfileを使用してランパーを構築します。

 FROM ubuntu:14.04 MAINTAINER Dmitry Orlov <me@mosquito.su> RUN apt-get update && \ apt-get install -y python-pip python-dev git && \ apt-get clean ADD . /tmp/build/ RUN pip install --upgrade --pre /tmp/build && rm -fr /tmp/build ENTRYPOINT ["/usr/local/bin/lumper"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、FROMは、画像がどの画像に基づいているかについて説明します。 次に、RUNは環境を準備するコマンドを実行します。 ADDはコードを/ tmp / buildに配置し、ENTRYPOINTはコンテナへのエントリポイントを示します。 したがって、起動時にdocker run -it --rm mosquito / lumper --helpと記述すると、出力--help entrypointが表示されます 。

おわりに

サーバーでコンテナを実行するには、いくつかの方法があります。initスクリプトを記述するか、コンテナからソリューション全体を展開できるFigを見てください。



また、ポートフォワーディングとコンテナのIPルーティングのトピックも意図的に無視しました。



また、この技術は若​​いため、Dockerには巨大なコミュニティがあります。 そして素晴らしいドキュメント 。 ご清聴ありがとうございました。