资讯专栏INFORMATION COLUMN

docker-compose: scale and link

CoreDump / 2087人阅读

摘要:更多文章访问的小博客

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的小博客

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/26685.html

相关文章

  • 从docker到istio之二 - 使用compose部署应用

    摘要:使用导出端口,使用挂载数据卷。清理应用使用一键清理应用总结已经实现了容器扩容自动挡更直观的控制容器启动顺序及依赖。从部署到编排,单字面理解,看起来能够维护的容器量都增长了。推荐应用包括多个服务,推荐部署方式就是。前言 容器化,云原生越演越烈,新概念非常之多。信息爆炸的同时,带来层层迷雾。我尝试从扩容出发理解其脉路,经过实践探索,整理形成一个入门教程,包括下面四篇文章。 容器化实践之路-从d...

    yy13818512006 评论0 收藏0
  • 一步步学会用docker部署应用(nodejs版)

    摘要:本文将采用技术部署一个简单的应用,它包括一个简单的前置网关服务器以及业务服务器。同时使用配置特定镜像,采用进行容器编排,解决依赖网络等问题。服务器首先搭建一个单节点缓存服务,采用官方提供的最新版镜像,无需构建。 docker是一种虚拟化技术,可以在内核层隔离资源。因此对于上层应用而言,采用docker技术可以达到类似于虚拟机的沙盒环境。这大大简化了应用部署,让运维人员无需陷入无止境繁琐...

    canger 评论0 收藏0
  • 一步步学会用docker部署应用(nodejs版)

    摘要:本文将采用技术部署一个简单的应用,它包括一个简单的前置网关服务器以及业务服务器。同时使用配置特定镜像,采用进行容器编排,解决依赖网络等问题。服务器首先搭建一个单节点缓存服务,采用官方提供的最新版镜像,无需构建。 docker是一种虚拟化技术,可以在内核层隔离资源。因此对于上层应用而言,采用docker技术可以达到类似于虚拟机的沙盒环境。这大大简化了应用部署,让运维人员无需陷入无止境繁琐...

    BlackMass 评论0 收藏0
  • Docker Swarm在生产环境中的进阶指南

    摘要:应该如何解决本文将给出若干提示,如何在生产环境中使用。路由匹配服务发现负载均衡跨容器通讯非常可靠。在单个端口上运行一个服务,节点的任意主机都可以访问,负载均衡完全在后台实现。 上周数人云给大家分享了——《你可能需要的关于Docker Swarm的经验分享》今天给大家带来这位作者大大的后续文章——《Docker Swarm在生产环境中的进阶指南》 当在本地开发环境中使用Docker,或者...

    galaxy_robot 评论0 收藏0
  • scrapy_redis 和 docker 实现简单分布式爬虫

    摘要:简介在使用爬取桔子公司信息,用来进行分析,了解创业公司的一切情况,之前使用写了一个默认线程是的单个实例,为了防止被设置了下载的速度,万多个公司信息爬了天多才完成,现在想到使用分布式爬虫来提高效率。 简介 在使用 scrapy 爬取 IT桔子公司信息,用来进行分析,了解 IT 创业公司的一切情况,之前使用 scrapy 写了一个默认线程是10的单个实例,为了防止被 ban IP 设置了下...

    _DangJin 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<