docker-compose: scale and link

CoreDump 發(fā)布于2019-06-28 15:20 / 2195人閱讀

摘要：更多文章訪問的小博客

Learned how to use docker compose to create a scalable web app with nginx.

Month ago, I built my apps with docker and used Nginx outside the docker as a reverse proxy server. Now I have something better to make a change.
In docker"s world, every component of a website should running as a container, include app, db, and Nginx as well.
A docker compose YAML I found online as follows, from a blog:

nginx:
    build: ./nginx
    links:
        - node1:node1
        - node2:node2
        - node3:node3
    ports:
        - "80:80"
node1:
    build: ./node
    links:
        - redis
    ports:
        - "8080"
node2:
    build: ./node
    links:
        - redis
    ports:
        - "8080"
node3:
    build: ./node
    links:
        - redis
    ports:
        - "8080"
redis:
    image: redis
    ports:
        - "6379"

The author made 3 app containers, 1 redis container and 1 nginx container. I find some ugly implement here that each node is hard coded in conf file, so if nodes need to be scaled up, we should add more and more nodes in the conf file.
docker compose scale is a useful command here to let us scale up our app containers elegantly. docker compose scale node=3 nginx=1 redis=1 will automatically create 3 node containers for us.
But there is another dark cloud on the sky. In the previous version, nginx config file is simply as follows:

worker_processes 4;

events { worker_connections 1024; }

http {

        upstream node-app {
              least_conn;
              server node1:8080 weight=10 max_fails=3 fail_timeout=30s;
              server node2:8080 weight=10 max_fails=3 fail_timeout=30s;
              server node3:8080 weight=10 max_fails=3 fail_timeout=30s;
        }
         
        server {
              listen 80;
         
              location / {
                proxy_pass http://node-app;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Host $host;
                proxy_cache_bypass $http_upgrade;
              }
        }
}

Can we use node to replace node1,node2,node3 here?
node1 here is not some docker magic, it"s just a hostname which docker generated in /ets/hosts of nginx container, since we linked node1 to nginx.
So if we have 3 node IP which has the same hostname, we can just rewrite conf to a single server:

        upstream node-app {
              least_conn;
              server node:8080 max_fails=3 fail_timeout=30s;
        }

Unfortunately, docker compose v1 seems not support group nodes into the same hostname.
It will generate hosts as follows:

172.17.0.21 node 8a1297a5b3e4 compose_node_1
172.17.0.21 node_1 8a1297a5b3e4 compose_node_1
172.17.0.22 node_2 069dd46836aa compose_node_2

Only one container will get the name node. After searching in Github, I got some interesting facts:

The interaction of scaling with networking (as with links) is unsatisfactory at the moment - you"ll basically get a bunch of entries in /etc/hosts along these lines:

  172.16.0.1 myapp_php_1
  172.16.0.2 myapp_php_2
  172.16.0.3 myapp_php_3

In a future version of Compose (enabled by changes to Engine), the name under which each container joins the network is going to change to just the service name, php. So you"ll get multiple entries with the same name:

172.16.0.1 php
172.16.0.2 php
172.16.0.3 php

This isn"t a real solution either, of course - we"re still working towards one - but in both cases, if you have a load balancer container that needs to keep up-to-date with what"s currently on the network, for the time being it"ll need to periodically read /etc/hosts and parse the entries to determine the IPs of the backends.

@aanand one of the maintainer of docker compose said above in 2015-12-7.

It may already be improved in v2 with docker 1.10, but I have not get the chance to use docker 1.10.

I think this way is better since we can easily scale up and dont need to change the config. DevOps should evolve in this way.

更多文章訪問 kamushin的小博客

GPU云服務器云服務器 docker-compose Scaling Scale scale html

文章版權歸作者所有，未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/26685.html

從docker到istio之二 - 使用compose部署應用

摘要：使用導出端口，使用掛載數(shù)據(jù)卷。清理應用使用一鍵清理應用總結已經(jīng)實現(xiàn)了容器擴容自動擋更直觀的控制容器啟動順序及依賴。從部署到編排，單字面理解，看起來能夠維護的容器量都增長了。推薦應用包括多個服務，推薦部署方式就是。前言容器化，云原生越演越烈，新概念非常之多。信息爆炸的同時，帶來層層迷霧。我嘗試從擴容出發(fā)理解其脈路，經(jīng)過實踐探索，整理形成一個入門教程，包括下面四篇文章。容器化實踐之路-從d...

yy13818512006 2019-05-23 14:14 評論0 收藏0
一步步學會用docker部署應用（nodejs版）

摘要：本文將采用技術部署一個簡單的應用，它包括一個簡單的前置網(wǎng)關服務器以及業(yè)務服務器。同時使用配置特定鏡像，采用進行容器編排，解決依賴網(wǎng)絡等問題。服務器首先搭建一個單節(jié)點緩存服務，采用官方提供的最新版鏡像，無需構建。 docker是一種虛擬化技術，可以在內(nèi)核層隔離資源。因此對于上層應用而言，采用docker技術可以達到類似于虛擬機的沙盒環(huán)境。這大大簡化了應用部署，讓運維人員無需陷入無止境繁瑣...

canger 2019-08-23 15:33 評論0 收藏0
一步步學會用docker部署應用（nodejs版）

摘要：本文將采用技術部署一個簡單的應用，它包括一個簡單的前置網(wǎng)關服務器以及業(yè)務服務器。同時使用配置特定鏡像，采用進行容器編排，解決依賴網(wǎng)絡等問題。服務器首先搭建一個單節(jié)點緩存服務，采用官方提供的最新版鏡像，無需構建。 docker是一種虛擬化技術，可以在內(nèi)核層隔離資源。因此對于上層應用而言，采用docker技術可以達到類似于虛擬機的沙盒環(huán)境。這大大簡化了應用部署，讓運維人員無需陷入無止境繁瑣...

BlackMass 2019-06-28 17:06 評論0 收藏0
Docker Swarm在生產(chǎn)環(huán)境中的進階指南

摘要：應該如何解決本文將給出若干提示，如何在生產(chǎn)環(huán)境中使用。路由匹配服務發(fā)現(xiàn)負載均衡跨容器通訊非常可靠。在單個端口上運行一個服務，節(jié)點的任意主機都可以訪問，負載均衡完全在后臺實現(xiàn)。上周數(shù)人云給大家分享了——《你可能需要的關于Docker Swarm的經(jīng)驗分享》今天給大家?guī)磉@位作者大大的后續(xù)文章——《Docker Swarm在生產(chǎn)環(huán)境中的進階指南》當在本地開發(fā)環(huán)境中使用Docker，或者...

galaxy_robot 2019-06-28 15:46 評論0 收藏0
scrapy_redis 和 docker 實現(xiàn)簡單分布式爬蟲

摘要：簡介在使用爬取桔子公司信息，用來進行分析，了解創(chuàng)業(yè)公司的一切情況，之前使用寫了一個默認線程是的單個實例，為了防止被設置了下載的速度，萬多個公司信息爬了天多才完成，現(xiàn)在想到使用分布式爬蟲來提高效率。簡介在使用 scrapy 爬取 IT桔子公司信息，用來進行分析，了解 IT 創(chuàng)業(yè)公司的一切情況，之前使用 scrapy 寫了一個默認線程是10的單個實例，為了防止被 ban IP 設置了下...

_DangJin 2019-07-31 12:21 評論0 收藏0