![]() ![]() ![]() ![]() Starting a Project from Multiple Compose Configuration Files Again, this is a bit of overkill for our purposes here, but it does provide a nice example of the capability. This gives the ability to startup a project with different configurations depending on the situation, for example using one configuration during development and another for production. However, let’s use another Compose feature that allows us to start up a project using more than one configuration file. We also need to add a top-level volumes key volumes:Īs with bind mounts in Part 4b, we can simply add this code to our Compose file to put our named volumes into action. Then the code we need to add to the MariaDB service is volumes:Īnd the code we need to add to the WordPress service is volumes: The code needed to add a named volume to our service configurations is very similar to that used for bind mounts. Let’s explore named volumes further by adding one to the MariaDB and WordPress services in our WordPress app. Another difference is that we must also specify a top-level volumes key with each named volume in our project listed as a sub-topic. As with the bind mount, we use the volumes sub-topic key in our Compose file to specify a named volume, with the difference that we use a name:container format. They also make it easy to share data between services in a project. Named volumes provide a second means to persist an app’s data between sessions. Exploring Named Volumes with Our WordPress App For the remainder of this post we will continue working with our project from Part 4b. If you need an overview of Docker data storage options before we move on you can read Docker’s storage overview. We’ll also look at how to start up a project with multiple Compose files. In Part 4c, we’ll continue discussing data storage within Docker, focusing on the named volume option for persistent data storage. In Part 4b we examined the bind mount option for persistent data storage. In Part 4a we saw that Docker created anonymous volumes to store our data absent our specifying a storage option in our Compose file. Part 9b – Hosting Bitwarden behind a reverse proxy server.Part 9a – Installing and configuring a Bitwarden password manager.Part 8 – Hosting multiple WordPress sites on a single database server.Part 7b – Securing network communications with your own certificate authority.Part 7a – Creating your own certificate authority.Part 6 – Securing network communications with self-signed certificates.Part 5 – Securing passwords with Docker secrets.Part 2 – Adding a database management tool.Part 1 – Series introduction and creating a simple WordPress app.This is Part 4c in a series describing a project to create a local WordPress development environment using Docker-Compose. If you’d just like to dive into the code for adding storage volumes to the WordPress app from the Part 3, you can skip ahead to Part 4d – Working with Data Storage in Docker Compose. We’re continuing our examination of Docker data storage options. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |