Docker：あらゆる場面でNATを使用しない柔軟なネットワーク

• デフォルトのブリッジネットワーク。
• ホストネットワーク;
• ユーザー定義ネットワーク。

• サーバーにサービスを配置するマップがあります。
• 各サービスとそのタイプ（または多数ある場合はタイプ）のポートマップがあります。
• ポートは一意でなければならないという合意があります。

• --net = hostを使用して同じマシン上で複数のサービスを実行すると、ポートの交差は発生しません。すべてが開始されて動作します。
• 1つのethインターフェースだけでは不十分な場合は、別のethインターフェースを物理的に接続し、たとえばDNSを介して、インターフェース間で負荷を分散します。

• サービスは重要です。
• コンテナに対して最も透明で高速なサービスを提供するための十分な経験の欠如;
• 「あなたの好みに何か他のものを追加する」ことができます。

• 1つのコアで動作します（はい、起こります）。
• 最初のギャップを埋めるには、いくつかのサービスインスタンスを実行し、 taskset /-cpuset-cpusを使用できることに注意してください。
• サービスは「大量に」ネットワークを使用し、発信接続には多数のポートが必要です。

• サービスの引き上げが予定されているマシンでは、追加のIPアドレス（または複数）を追加する必要がありました-ip a add （ここで、このアプローチの多くの欠点をすぐに指摘できます）。
• 上記については、たとえば、異なるマシンで2つの同一のアドレスを取得しないことを忘れないでください。
• デーモンの構成では、近隣またはホストシステムのすべてのポートを「食べない」ように、動作するアドレスを指定する価値がありました。

• すべてをそのままにしますが、コンテナに包みます。
• 同じ追加IPアドレスをすべてdockerhostに上げます。
• 特定のアドレスにアプリケーションを「バインド」します。

• アクティブなネットワーク機器の1つのリンクから1つのMACアドレスの制限はありません。
• ホスト上のコンテナの数はそれほど多くないため、Macの容量が過剰になる可能性があります。 時間の経過とともに、私たちのこの瞬間はもちろん変わります。
• L3はこの段階では必要ありません。

さあ、行こう！

# docker network create -d macvlan --subnet=1.1.1.0/24 --gateway=1.1.1.1 -o parent=eth0 cppbig_vlan Error response from daemon: plugin not found
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 docker[2012]: time="2016-08-04T11:44:44.095241242Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 1s" docker[2012]: time="2016-08-04T11:44:45.095489283Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 2s" docker[2012]: time="2016-08-04T11:44:47.095750785Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 4s" docker[2012]: time="2016-08-04T11:44:51.095970433Z" level=warning msg="Unable to locate plugin: macvlan, retrying in 8s" docker[2012]: time="2016-08-04T11:44:59.096197565Z" level=error msg="Handler for POST /v1.23/networks/create returned error: plugin not found"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• --net =ホスト ;
• --net = macvlan

 # docker run -it --net=host --name=iperf_w_host_net --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest # iperf3 -s -p 12345 ----------------------------------------------------------- Server listening on 12345 -----------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # iperf3 -c 1.1.1.2 -p 12345 -t 30
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # iperf3 -c 1.1.1.2 -p 12345 -t 30 -P 8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # docker run -it --net=cppbig_vlan --name=iperf_w_macvlan_net --ip=1.1.1.202 --entrypoint=/bin/bash dockerio.badoo.com/itops/sle_12_base:latest # iperf3 -s -p 12345 ----------------------------------------------------------- Server listening on 12345 -----------------------------------------------------------
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # iperf3 -c 1.1.1.202 -p 12345 -t 30
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # iperf3 -c 1.1.1.202 -p 12345 -t 30 -P 8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• サービスの可用性チェックの一部は、サービスが実行されているホストで実行されるZabbixヘルパーによってチェックされます。
• ホストシステムにあるキャッシュDNSを使用する必要があります。 私たちの場合、これはUnboundです。
• ホストシステムで実行されている他のサービスへのアクセスを使用する必要があります。
• これは、「ホスト<==>コンテナ」にアクセスする必要がある理由の一部にすぎません。 そのようなノードのアーキテクチャを一晩で取得して再構築することは不可能です。

1. マシンで2つ以上の物理リンクを使用します。 これにより、隣接するインターフェイスを介した対話が可能になります。 たとえば、eth1をMACVLAN専用に指定し、ホストシステムでeth0を引き続き使用します。 もちろん、このオプションは悪くありませんが、これには、このようなサービスを開始する予定のすべてのマシンで同じ数のリンクを維持する必要があります。 これを実装するのは費用がかかり、高速ではなく、常に可能ではありません。
   
   
   
   
2. ホストシステムで別の追加IPアドレスを使用し、仮想MACVLANインターフェイスでハングアップします。これはホストシステムで発生させる必要があります。 前の文が今回と同じように、サポートの面でも（「忘れないでください」/「忘れないで」）難しいです。 そして、私たちのサービス自体がそのようなサービスを開始するために最終的に追加のアドレスを必要とすることを以前に言ったので、私たちは必要です：
   
   
   
   
   • ホストシステムのメインインターフェースのアドレス（1）;
   • サービスのアドレス（2）;
   • サービスとやり取りする仮想インターフェイスのアドレス（3）。
   
   
   この場合、必要なIPアドレスが多すぎることがわかります。これは、通常、少し使用されます。 過剰なIPアドレスに加えて、この仮想インターフェイスを介してコンテナへの静的ルートを維持する必要があることも忘れてはなりません。 これは克服できない複雑さではありませんが、システム全体の複雑さは事実です。
   
   
   
   気配りのある読者は、「メインインターフェイスのアドレスを仮想インターフェイスに提供できるのに、なぜメインインターフェイスとMACVLANインターフェイスのアドレスなのか？」という質問をします。この場合、システムを実際のインターフェイスのアドレスなしのままにしますが、まだそのような一歩を踏み出す準備はできていません。
   
   
   
   前の2つのバージョンでは、すべてのインターフェイスのアドレスが同じネットワークに属していると想定されていました。 このようなサブネットに100台のサーバーがある場合でも、3つのアドレスで起動した場合、 / 24に入らないと想像するのは簡単です。
   
   
   
   
3. サービスIP。 このアイデアの本質は、サービス用に個別のサブネットを作成することです。 それはどのように見えますか：
   
   
   
   
   • 「タグ付き」トラフィックをサーバーに送信し始めます。
   • ネイティブVLANをdockerhost（eth0）のメインネットワークとして残します。
   • ホストシステムのIPアドレスなしで、802qを使用して仮想インターフェイスを上げます。
   • サービスにはサービスネットワークのIPアドレスを使用します。

• 「タグ付き」トラフィックをインターフェイスに配信するには、誰が必要ですか？ そうです、ネットワーク担当者！ アクセスポートを2つのVLANにフィードするポートに切り替えるように依頼します。
  
  
  
  
• ホストで追加のインターフェースを上げます：
  
  
  
  

   # cat /etc/sysconfig/network/ifcfg-vlan8 BOOTPROTO='static' STARTMODE='auto' VLAN='yes' ETHERDEVICE='eth0' # ip -d link show vlan8 31: vlan8@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether e4:11:5b:ea:b6:30 brd ff:ff:ff:ff:ff:ff promiscuity 1 vlan protocol 802.1Q id 8 <REORDER_HDR>
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• DockerでMACVLANネットワークを取得する
  
  
  
  

   # docker network create -d macvlan --subnet=1.1.2.0/24 --gateway=1.1.2.1 -o parent=vlan8 c_services
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

  
  
  
• Dockerのネットワークが表示されることを確認します。
  
  
  
  

   # docker network ls | grep c_services a791089219e0 c_services macvlan
        
        
  
          
          
          
        
  
      
          
          
          
        
        
  
          
          
          
        
  
      
       

 -t nat -A OUTPUT -d 127.0.0.11 -p udp --dport 53 -j DNAT --to-destination 127.0.0.11:35373 -t nat -A POSTROUTING -s 127.0.0.11 -p udp --sport 35373 -j SNAT --to-source :53 -t nat -A OUTPUT -d 127.0.0.11 -p tcp --dport 53 -j DNAT --to-destination 127.0.0.11:41214 -t nat -A POSTROUTING -s 127.0.0.11 -p tcp --sport 41214 -j SNAT --to-source :53
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # modinfo xt_nat filename: /lib/modules/4.4.0-3.1-default/kernel/net/netfilter/xt_nat.ko alias: ip6t_DNAT alias: ip6t_SNAT alias: ipt_DNAT alias: ipt_SNAT author: Patrick McHardy <kaber@trash.net> license: GPL srcversion: 9982FF46CE7467C8F2361B5 depends: x_tables,nf_nat intree: Y vermagic: 4.4.0-3.1-default SMP preempt mod_unload modversions
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• Dockerの問題;
• ソースコードに。

  if out, err := exec.Command("modprobe", "-va", "nf_nat").CombinedOutput(); err != nil { logrus.Warnf("Running modprobe nf_nat failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err) } if out, err := exec.Command("modprobe", "-va", "xt_conntrack").CombinedOutput(); err != nil { logrus.Warnf("Running modprobe xt_conntrack failed with message: `%s`, error: %v", strings.TrimSpace(string(out)), err) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

  if err := r.setupIPTable(); err != nil { return fmt.Errorf("setting up IP table rules failed: %v", err) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• （1および6）モバイルクライアントが特定のURLとの接続を確立し、その背後にバランサーが立つ;
• （2）バランサーがサービスの目的のインスタンスを選択し、クライアントとサービスの接続を確立できるようにします。
• （3および4）次に、サービスはコードを使用してクライアントからクラスターにリクエストをプロキシしますが、nginxの形式のバランサーも介します。 ここで、nginxがサービスと同じマシン上になければならないという要件に戻りました。 現時点では、コンテナ内ではなくホスト上にある必要があるという制限もあります（これにより、問題はすぐに解決されます）。 この記事では、この要件の理由については説明しませんが、条件として受け入れます。
• （5）サービスの各インスタンスには特定のIDがあり、コードはどの特定のインスタンスを介してクライアントに応答するかを理解する必要があります。

 # ip r default via 1.1.2.254 dev eth0 10.0.0.0/8 via 1.1.2.1 dev eth0 1.1.2.0/24 dev eth0 proto kernel scope link src 1.1.2.14 192.168.0.0/16 via 1.1.2.1 dev eth0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 # ip r default via 1.1.2.1 dev eth0 1.1.2.0/24 dev eth0 proto kernel scope link src 1.1.2.14
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• コンテナの名前空間を使用して手動で実行します。
• パイプワークhttps://github.com/jpetazzo/pipeworkを取り、同じことを行いますが、それを使用します。

1. デフォルトgwが1つのみで、外部バランサーが存在しないネットワーク。
   
   
   
   
   
   
   
   
   
   
   
   
2. 複数のGWを持つネットワーク：たとえば、外部要求バランサー。 難点は、内部トラフィックを通過させないことです。
   
   
   
   
   
   
   
   

• ルーティングを行うすべてのネットワークを監視し、責任を負う準備ができていません。
• 私たちの側では、サーバー上のすべてのそのようなネットワークの静的ルートをサポートする準備ができていません

• サービス自体;
• サービスの専用IP。
• すべてのサブネットからのサービスの可用性とアドレス。
• コンテナの起動時にルートを使用および変更する機能（最も重要なのは、これはまさに忘れることができるものだからです）。

 FROM dockerio.badoo.com/itops/sle_12_base:latest MAINTAINER #MAINTEINER# RUN /usr/bin/zypper -q -n in iproute2 RUN groupadd -g 1001 wwwaccess RUN mkdir -p /local/SERVICE/{var,conf} COPY get_configs.sh /local/SERVICE/ COPY config.cfg /local/SERVICE/ ADD SERVICE-CERTS/ /local/SERVICE-CERTS/ ADD SERVICE/bin/SERVICE-BINARY-${DVERSION} /local/SERVICE/bin/ ADD SERVICE/conf/ /local/SERVICE/conf/ COPY routes.sh /etc/cont-init.d/00-routes.sh COPY env.sh /etc/cont-init.d/01-env.sh COPY finish.sh /etc/cont-finish.d/00-finish.sh COPY run /etc/services.d/SERVICE/ COPY finish /etc/services.d/SERVICE/ RUN touch /tmp/fresh_container ENTRYPOINT ["/init"]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

• コンテナ内のスーパーバイザーとしてs6オーバーレイを使用します。
• ルートを編集できるようにiprouteパッケージを追加します。
• サービスの開始前に実行されるいくつかのスクリプトの起動（ディレクトリ/etc/cont-init.d/）を追加し、サービスが終了した後に実行されるスクリプトを追加しますが、コンテナがドロップする前に（/ etc / cont -finish.d /）;
• コンテナが初めて起動するかどうかを理解するために、ファイル/ tmp / fresh_containerを追加します。 残りのスクリプトの内容を表示すると、少し明確になります。

1. get_configs.shは、システムに設定を保存および生成するためのサービスの設定があるかどうかを確認するスクリプトで、設定をコンテナに配信し、有効性をチェックし、すべてが正常である場合、それとともに起動します。 これについては、 Docker Meetupで詳しく説明しました。
   
   
   
   
2. routes.sh-コンテナ内のルートを準備するスクリプト：
   
   
   
   

    #!/usr/bin/with-contenv sh if [ ! -x /usr/sbin/ip ];then echo -e "\e[31mCan't execute /usr/sbin/ip\e[0m"; [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services exit 1; else LTMGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".254"'}) DEFGW=$(/usr/sbin/ip r show | /usr/bin/grep default | /usr/bin/awk {'print $3'} | /usr/bin/awk -F \. {'print $1"."$2"."$3".1"'}) /usr/sbin/ip r replace default via ${LTMGW} /usr/sbin/ip r add 192.168.0.0/16 via 10.10.8.1 dev eth0 /usr/sbin/ip r add 10.0.0.0/8 via 10.10.8.1 dev eth0 echo -e "\e[32mAll job with routes done:\e[0m\n$(/usr/sbin/ip r show)" fi
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
3. env.sh-サービスの環境を準備するスクリプト。 多くの場合、コンテナの最初の起動時に1回だけ実行されます。
   
   
   
   

    #!/usr/bin/with-contenv sh if [ ! -z "${ISTEST}" ];then exit 0;fi if [ ! -n "${SERVICETYPE}" ];then echo -e "\e[31mPlease set SERVICE type\e[0m"; [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services exit 1; fi bash /local/SERVICE/get_configs.sh || exit 1 echo -e "\e[32mSERVICE ${SERVICETYPE} is running\e[0m"
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
4. finish.shは、サービスからpidファイルを単純に削除するスクリプトです。 特定のサービスは（Chuck Norrisのように）とてもクールなので実行しませんが、古いpidファイルを検出すると開始されません:)
   
   
   
   
5. runは、アプリケーションを起動するスクリプトです。
   
   
   
   

    #!/usr/bin/with-contenv bash exec /local/SERVICE/bin/SERVICE-${DVERSION} -l /local/SERVICE/var/mobile-${SERVICETYPE}.log -P /local/SERVICE/var/mobile-${SERVICETYPE}.pid -c /local/SERVICE/conf/SERVICE.conf -v ${VERBOSITY}
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
6. finish-サービスが作業を完了した場合にコンテナを消滅させるスクリプト：
   
   
   
   

    #!/bin/sh [ $(pgrep s6-svscan) ] && s6-svscanctl -t /var/run/s6/services
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   

 docker run -d --net=c_services --ip=1.1.2.17 --name=SERVICE-INSTANCE16 -h SERVICE-INSTANCE16.local --cap-add=NET_ADMIN --add-host='nginx.localhost:1.1.1.17' -e SERVICETYPE=INSTANCE16_eu1 -e HOST_IP=1.1.1.17 --volumes-from=badoo_loop dockerio.badoo.com/cteam/SERVICE:2.30.0_994