コンテナ船のチャネルがブロックされている場合、コンテナにセイロンを組み立てる方法

親切で優しく反応の良い数学者（ DMOiM ）のチームでは 、 セイロンが汎用言語として使用されています。 レスポンシブであるため、この言語を使用するだけでなく、主にバグレポートなどの開発にも参加しています。 プルクエストではさらに悪化します。最初の理由は、オフィスではインターネットへの直接アクセスがなく、プロキシサーバーを経由するだけだからです。 （もちろん、時間がない。）







カットの下で、ソースコードからCeylonプロジェクトを構築するときに発生した問題と、それらの解決方法に関する正確な詳細。 最後に、彼女の究極の目標についてのいくつかの言葉もあります。

これはどんな象ですか

最初に、プロジェクトとしてのセイロンに関するいくつかの言葉。 （気にかけているプログラミング言語については、 こちらをお読みください 。）その中の2つの基本的なサブプロジェクト（IDEプラグインなどのツール、独自のリポジトリ）はceylonとceylon-sdkです。 最初のものには、コンパイラ自体とJavaで記述されたコンソールユーティリティのセットが含まれています。 2つ目は、Ceylon自体で記述されたコアライブラリのセットです。 各プロジェクトはApache Antを使用してビルドされます。もちろん、インストールされたJDKも必要です。



コンパイラーはant clean dist



コマンドを使用して構築されます。その後、dist / distディレクトリーから/ usr / local / share / ceylonまたは任意の場所にコピーし、$ PATHに表示されるディレクトリー内の実行可能ファイルへのリンクを作成できます。 ライブラリは収集され、 ant clean publish



コマンドで必要な場所にコピーされます。



インターネットへの直接アクセスにより（Java、Ant、およびCeylonのソースの必要なバージョンとともに）、アセンブリは問題なく行われます。

コース問題

弊社のセキュリティ要件は、ワークステーションとほとんどのサーバーからインターネットへの直接アクセスの欠如を規定しています。ローカルミラーとプロキシサーバーであらゆる状況に対応できることを前提としています。 しかし、反対のケースが発生します。 独自のプロジェクト用にCIを構成する場合でも、同僚はこのために苦しむ必要がありました。



オープンデッキでワークステーションのむき出しの鉄をコンパイルすると、コンパイラは静かに組み立てられました（おそらく、すべての依存関係がプロジェクトに含まれ、おそらく以前に行った設定が助けになったかもしれません）が、ライブラリセットはビルドされません ゲートウェイプロキシと、ライブラリ（Ceylon Herd、Maven Nexus）を備えたタンクがあるように見えますが、何かが欠落しています。 おそらく、「塩味スプレー、猛烈な風の突風...」ⓒバラッシュ。





面白いのは、ビルドシステムがCaven（Java）形式のMavenからのJava依存関係を必要とすることです。これは原則として存在するべきではありません。

コンテナ内の包装アセンブリ

コンテナとは何ですか、地元の観客は知っておくべきです。 リンク渡しの場合。



だから、成功しなかったので、私はインターネットに直接アクセスできるコンピューターで公海でセイロンとセイロンSDKを組み立て、この組み立て品をコンテナ内のオフィスネットワークに届けることにしました。 理論的には、コンテナにはすべての依存関係が含まれます。その後、必要に応じてコードを編集し、リクエストをプルして再構築を開始できます。



中間レベルとして、JDKを使用したイメージが準備されました。





Dockerfileは企業の構成から借用され、ロシア語ロケールの作成についてコメントされました。 その主なタスクは、Oracle JDK（補助プログラムを介して、Oracleライセンスにより）とMavenをインストールすることです。また、最初に更新され、最後にAPTのデータが消去されます。 明らかに依存関係として、Antも存在します。



次のステップ：アセンブリCeylonで画像を作成します。 イメージを作成するとき、ceylon-sourcesディレクトリはDockerfileの隣にある必要があり、ceylonおよびceylon-sdkプロジェクトが含まれている必要があります。 最初はgit cloneを画像作成に直接配置したかったのですが、ソースをローカルで編集しますが、2回クローンを作成しても意味がありません。



Dockerfile kopilov / ceylon_build：1.3.4-SNAPSHOT

 FROM kopilov/java8:latest #      ENV CEYLON_VERSION 1.3.4-SNAPSHOT #   APT ( ,    ), # git ( -    ) # netcat (   ) RUN apt-get update -y && \ apt-get install -y git && \ apt-get install netcat-traditional #    . , #   git clone,    ,   . WORKDIR /usr/src/ceylon ADD ceylon-sources /usr/src/ceylon # ,    WORKDIR /usr/src/ceylon/ceylon RUN ant clean dist && \ cp -a dist/dist /usr/local/share/ceylon-${CEYLON_VERSION} && \ ln -s /usr/local/share/ceylon-${CEYLON_VERSION}/bin/ceylon /usr/local/bin #  WORKDIR /usr/src/ceylon/ceylon-sdk RUN ant clean publish #  RUN apt-get clean && rm -rf /var/lib/apt/lists/*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このイメージのアセンブリは、インターネットに直接アクセスできる場合にのみ成功します。 組み立てた後、 hub.docker.comに投稿しました。

閉じたチャネルの再組み立て

完成したアセンブリを含むコンテナにはすべての依存関係が含まれることが期待されており、インターネットはもう必要ありません。 docker run -it kopilov/ceylon_build



から、 ant clean publish



docker run -it kopilov/ceylon_build



ます。





インターネットアクセスを無効にすると、イメージが作成されたコンピューターで同じエラーが発生します。 他に何が欠けていますか？ サメなしでは、トラフィックを把握することはできません。



インターネットアクセスをオフにすると、DockerからのトラフィックはWiresharkで次のようになります。







サーバーIP repo1.maven.orgの特定に何度か失敗すると、上記のエラーが表示されます。 しかし、接続が復元されるとどうなりますか：







パラドックス：システムは、404エラー応答を取得するためにGET要求を作成し、その後、落ち着いてビルドを続けます。 そして、彼女がこのリクエストを満たさない場合、ユーザーはそのGETリクエストとまったく直交するエラーを受け取ります。 以下に、HTTPSを介したmodules.ceylon-lang.org（別名Herd ）に対するリクエストを見ることができますが、最初に最初のリクエストを見つけてください。



最初に決定したのは、行「127.0.0.1 repo1.maven.org」を/ etc / hostsファイルに追加することでした。 ここで、「404 NOT FOUND」という答えを何らかの方法で模倣する必要があります。 最近のhabrasurfingは、netcat（ proof ）が最も単純なWebサーバーとして機能できることを示しました。 アセンブリを開始する前（ただし、コンテナを開始した後）に並列ターミナルを入力します

 docker container ls # _ docker exec -it _ bash nc -lp 80
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、アセンブリ（ant）を開始し、netcatを使用して端末にGETリクエストが表示されるのを待ち、応答して印刷します

HTTP/1.1 404 NOT FOUND

Server: nc









出来上がり！ アセンブリはさらに進んだ！ 次に、システムは（JavaScriptでビルドする場合）まったく同じ要求を1つ行い、プロセスは正常に完了します。

上記の自動化とライブラリの改良

準備されたイメージには、元のCeylon SDKライブラリのアセンブリが含まれており、最終的な目標は変更されたライブラリをアセンブルすることでした。 そのため、別のDockerfileが作成され、ソースが置き換えられました。

 FROM kopilov/ceylon_build:1.3.4-SNAPSHOT ENV CEYLON_VERSION 1.3.4-SNAPSHOT WORKDIR /usr/src/ceylon/ceylon-sdk RUN rm -rf * ADD ceylon-sources/ceylon-sdk .
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それは可能な限り単純でなければなりませんでした（結局、イメージはテストの再構築ごとに、ほぼすべてのソースリビジョンに対して再作成されます）、これがnetcatが事前にインストールされた理由です。 netcatのトリックは、次のスクリプト（plug.sh）でラップされました。

 #!/bin/bash IMAGE_NAME="kopilov/ceylon_patch_src" CONTAINER_ID=$(docker container ls | grep "${IMAGE_NAME}" | sed 's/ .*//') docker exec -i $CONTAINER_ID bash << END echo "127.0.0.1 repo1.maven.org" >> /etc/hosts echo "HTTP/1.1 404 NOT FOUND" > /tmp/notfound echo "Server: nc" >> /tmp/notfound echo "" >> /tmp/notfound nc -lp 80 < /tmp/notfound nc -lp 80 < /tmp/notfound END
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナ（get_built_ceylon.sh）からアセンブリを取得する別のスクリプト：

 #!/bin/bash CONTAINER_ID=$(docker container ls -a | grep kopilov/ceylon_patch_src | sed 's/ .*//') rm -r ~/.sdkman/candidates/ceylon/1.3.4-SNAPSHOT/ docker cp $CONTAINER_ID:/usr/local/share/ceylon-1.3.4-SNAPSHOT . mv ceylon-1.3.4-SNAPSHOT /home/akopilov/.sdkman/candidates/ceylon/1.3.4-SNAPSHOT rm -r ~/.ceylon/repo/ docker cp $CONTAINER_ID:/root/.ceylon/repo ~/.ceylon
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さらに、合理化への欲求は枯渇し、手作業で行動することに変わりはありませんでした。 ソースを編集するたびに、最初にターミナルの1つのタブでdocker build -t kopilov/ceylon_patch_src . && docker run -it kopilov/ceylon_patch_src



docker build -t kopilov/ceylon_patch_src . && docker run -it kopilov/ceylon_patch_src



、次に隣接する./plug.sh



、そして再び最初のant clean publish



ます。 また、アセンブリにエラーが発生しなかった場合（およびテストするものが既にある場合）-./ ./get_built_ceylon.sh

結果と起源

「将来に向けて」行われた作業の主な結果は、プロジェクトの上流に事前にテストされたプルリクエストを送信する（そしておそらくだけではない）チームの能力でした。 現時点では、私は個人的にこれを送信し、途中で書かれました： github.com/ceylon/ceylon-sdk/pull/688



Dockerイメージkopilov / java8およびkopilov / ceylon_buildは、必要に応じてhub.docker.comで入手できます。



それはすべて、先週、私は非常に緊急で、非常に緊急のタスクでさえなく、部門の長でさえどこかに去ったという事実から始まりました。 そして、彼は次のように述べました。「他の有用なものをプロジェクトに固定できると考えてください。」（プロジェクトはプロトタイプ段階です。）



PS

KDPVバックグラウンドソース