Docker:如何Dockerize并部署LAMP应用程序的多个实例 [英] Docker : How To Dockerize And Deploy multiple instances of a LAMP Application

查看:192
本文介绍了Docker:如何Dockerize并部署LAMP应用程序的多个实例的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我需要部署许多相同LAMP(或LEMP)应用程序的实例:




  • 每个实例每个实例都必须拥有自己的数据库数据和文件数据。每个实例都可能是一个子域,可以从一个子域访问,前端负载均衡器/代理

  • <监视
  • 可以为每个应用实例设置内存限制/ cpu

  • 轻松自动部署新的webapp实例

  • 环境可能会很容易地重复测试和开发。



应用程序需要:




  • dameon进程( Nginx MariaDB PHPFPM

  • 二进制(作曲家 bower ,...)

  • 其他系统特定的libs&配置



在阅读Docker文档和许多howtos之后,我看到了不同的解决方案来停靠此Web应用程序: / p>




解决方案1:使用一体式集装箱



所有堆栈都在一个容器中:




  • webapp源文件,EMP守护程序进程,二进制文件... ...

  • 装载的卷为 mysql 和webapp数据文件



示例:





优点(IMHO):




  • 似乎很容易自动淘汰,监视器,摧毁...。

  • 易于在prod,test和dev环境中使用。



缺点(IMHO):




  • Monolithic


  • 不使用Docker的所有实力






解决方案2:每个webapp实例使用容器堆栈



对于要部署的每个webapp,部署了一个容器堆栈:




  • 每个进程一个容器: Nginx Mysql PHP-FPM

  • 二进制容器( composer bower ,...)也可以进行dockerized,或合并到phpfpm容器中。

  • 装载卷对于mysql和webapp数据文件



示例:





Pro (IMHO):




  • 解耦

  • 每个实例隔离的进程

  • 每个容器一个进程,不需要守护进程管理器作为RUnit或
    Supervisord



缺点(IMHO):




  • 似乎更复杂的工作

  • 很难维护,看到所有集装箱状态,链接,版本的大图...






解决方案3:混合以前的2个解决方案




  • 一个app容器,包括:app src文件,nginx,phpfmp,composer,git ..

  • 一个用于db mysql的容器,可以与应用程序容器共享






我比起Ops更重要,也让我感到困惑。



所以问题: p>


  1. 在这些解决方案之间进行选择时,要考虑的优点/缺点是什么?

  2. 如何管理所有容器堆栈,如果我选择解决方案2,对所有容器状态,链接,版本...有一个大图?

  3. 应用程序src文件(PHP)可能内置在容器中或作为卷安装,例如。 / var / www?


解决方案

我最近通过Docker分析了这种类型的设置。我知道有一些人将Docker视为一种MicroVM,但我认为Docker的理念更倾向于逐个容器的单一过程。这与编程中的单一责任原则相一致。 Docker容器做的越多,可重用性越差,管理难度越大。我在这里发布了所有想法:



http:/ /software.danielwatrous.com/a-review-of-docker/



然后我继续使用Docker构建一个LEMP堆栈。在将PHP和Nginx进程分割成单独的Docker容器时,并没有发现很多价值,但Web和数据库功能是分开的容器。我还展示了如何管理链接和卷共享,以避免在容器中运行SSH守护进程。你可以按照我在这里作为参考点。



http://software.danielwatrous.com/use-docker-to-build-a-lemp-stack-buildfile/



对于每个容器的单个功能增加复杂性,您是正确的。它的外观和感觉就像你有不同的分布式层次。非常大的应用程序已经做了这么多年,并且确实增加了在通信,安全和管理方面的复杂性。当然,这也带来了许多好处。


I need to deploy many instances of the same LAMP (or LEMP) application :

  • each instance will be accessible from a subdomain, with front loadbalancer/ proxy
  • each instance must have its own db data and files data.
  • each instance might be monitored
  • memory limit / cpu might be set per app instance
  • easy to automate the deployment of an new webapp instance
  • environment might be easily reproducible for test and development.

Application requires :

  • dameon processes (Nginx, MariaDB, PHPFPM)
  • binaries (composer, bower, ...)
  • other systems specific libs & config

After reading Docker documentation and many howtos, I see different solutions to dockerize this web application :


Solution 1 : Use an all-in-one Container

All the stack is in one container :

  • webapp source files, EMP daemon processes, binaries, …
  • mounted volumes for mysql and webapp data files

Examples :

Pros (IMHO) :

  • Seems easy to automate deploiement, to monitor, to destroy….
  • Easy to use in prod, test and dev environment.

Cons (IMHO):

  • Monolithic
  • Hard to scale
  • Does not use all the strength of Docker

Solution 2 : Use a containers stack per webapp instance

For each webapp to deploy, a containers stack is deployed :

  • One container per process : Nginx, Mysql, PHP-FPM,
  • Binary containers (composer, bower,...) can be also dockerized, or merged in the phpfpm container
  • mount volumes for mysql and webapp data files

Examples :

Pro (IMHO) :

  • Decoupled
  • processes isolated per instance
  • One process per container, no need daemon manager as RUnit or Supervisord

Cons (IMHO) :

  • Seems more complicated to do work
  • Hard to maintain, to see a "big picture" of all containers states, links, version...

Solution 3 : Mixin the 2 previous solutions

  • One "app" container with : app src files, nginx, phpfmp, composer, git..
  • One container for db mysql, which can be shared or not with the app container

I'm more Dev than Ops, also it's confused for me.

So, Questions :

  1. What are the criteria, pros/cons to consider when choosing between theses solutions?
  2. Howto to manage all the containers stacks if i choose Solution 2, to have a "big picture" of all containers states, links, version... ?
  3. App src files (PHP) might be built in the container or mounted as volume, eg. /var/www ?

解决方案

I recently went through analysis on Docker for this type of setup. I know there are some who view Docker as a sort of MicroVM, but my take is the Docker philosophy leans more toward single process per container. This tracks well with the Single Responsibility principle in programming. The more a Docker container does, the less reusable and more difficult to manage. I posted all my thoughts here:

http://software.danielwatrous.com/a-review-of-docker/

I then went on to build a LEMP stack using Docker. I didn't find a lot of value in splitting the PHP and Nginx processes into separate Docker containers, but the Web and Database functions are in separate containers. I also show how to manage linking and volume sharing to avoid running SSH daemons in your containers. You can follow what I did here as a point of reference.

http://software.danielwatrous.com/use-docker-to-build-a-lemp-stack-buildfile/

To your point about increased complexity for the single function per container, you are correct. It will look and feel just like you had distinct, distributed tiers. Very large applications have done this for years and it does increase complexity when it comes to communication, security and management. Of course it brings a number of benefits as well.

这篇关于Docker:如何Dockerize并部署LAMP应用程序的多个实例的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆