Docker – How does Docker work as far as being able to edit Apache config files and similar stuff

docker

I am interested in getting my head around the full concept of using Docker on my server for my web clients.

Ideally I would love to create a docker with apache, PHP, MySQL, email server, DNS server, redis, memcached, imagemagick, and more and have it where I can simply launch to a clients new server and be up in minutes.

I saw this Apcache Docker here https://hub.docker.com/r/eboraas/apache-php/

It says:

This is an Apache image including SSL and PHP5 support. In order to
use this image effectively, you'll need to mount:

/var/www for your site content (e.g. using "-v
/home/jdoe/mysite/:/var/www/") /var/log/apache2, optionally, if you
want to store logfiles visibly outside the container /etc/ssl,
optionally, if you wish to use SSL with real keys

More specificlly:

Mount /var/www for your site content

If I understand correctly this is to allow outside folder/files of websites to exist on the server outside of the Docker image so that Docker is basically just to handle the actual server software?

Some more questions:

Would things like Apache Virtualhost records for adding domains exist inside the docker image or on the server outside of it and be editable?

Best Answer

How does Docker work as far as being able to edit Apache config files and similar stuff?

Pretty much however you would like it to work. :)

If I understand correctly this is to allow outside folder/files of websites to exist on the server outside of the Docker image so that Docker is basically just to handle the actual server software?

Yes, that's correct.

Would things like Apache Virtualhost records for adding domains exist inside the docker image or on the server outside of it and be editable?

If you want/need them to exist outside the container, then build it that way.

As you've no doubt noticed, my answers to your questions have been fairly nebulous. There's a good reason for that. Just because you're using docker doesn't mean that there is one single good way to do things. Your use case will dictate to a large degree how you want to use docker.

In my environment, we have chosen to store all configuration and all application state outside of the container. For configuration, that means that we maintain an "etc" directory on the host that contains all configuration for each type of container running on that host. Likewise, we store state (database files, etc.) on the host's filesystem instead of using data volumes. Both configuration directories and data storage locations are mounted into running containers using the -v runtime flag. This architecture has worked out very well for us, but it may not be what your organization needs.

There are plenty of valid use cases for using completely self-contained docker images that include configuration, along with using data volumes for application state. You'll just need to enumerate your requirements and then work out a design that fulfills your requirements.

Docker is a tool for you to use. It's up to the user to determine how they're going to use it.

Related Topic