tj12
tj12

Reputation: 11

How should I containerize my application requiring apache/php/mysql with an authenticated and public site experience?

I’ve spent months building an application and now I’m looking to deploy it, but I’m new to Docker and I seem to have brain block when it comes to actually containerizing my application. I need to run the following technologies:

My application will need to be available exclusively through https and I’m assuming the connection between my application and the mysql container will also need to be through a secure port.

In addition to that I have a wordpress site that will serve as the pre-login experience for my application that I’d like to dockerize, but should not share the same DB. When I move this to a prod environment, I will not include the phpMyAdmin container.

How many containers do I need? I was thinking that I would need at least 5:

  1. apache
  2. php
  3. mysql (my application)
  4. mysql (wordpress)
  5. phpmyAdmin

Should my application and the worpress site live in the php container? or should I create separate containers for each.

What should my docker-compose.yml file and dockerfiles look like to achieve this feat?

Upvotes: 1

Views: 620

Answers (1)

CryptoFool
CryptoFool

Reputation: 23079

The driving idea here is that a container should contain a single "service". You don't break things into containers by software component (php, apache, etc.) but rather by whatever needs to be combined to create a single service. So if your application is a PHP application hosted by Apache, then you'd want a container for your application that contained PHP, Apache and your application code. That would provide your application as a service.

Same goes for Wordpress. If Wordpress is running behind Apache and needs PHP, you'd create a second container containing PHP, Apache, WordPress, and your WordPress content, producing your "Wordpress service".

Each of your individual databases can be seen as a service, so you might want two containers running MySQL, one serving each of your databases. You could choose to consider the database server as a whole to be a service, and have it serve both of your databases. Then you could get away with a single MySQL container. Which way you go with this is a minor issue. Having a single database server will likely save a little bit of resources by avoiding some duplication.

If all of your services need to talk to each other, the easiest way to do this with Docker is to use Docker Compose. This lets you create multiple containers that know about each other and can communicate very easily between each other by way of some simple DNS logic that Docker Compose provides. With Compose, you give each of your containers a simple name, and then that name can be looked up via DNS to provide the IP address of each container. So for example, if your MySql container was named "mysql", your app container could connect to it via the DNS address "mysql" with no additional work on your part.

Upvotes: 3

Related Questions