This is why I'm introducing Alpine so early on: instead of going for the first available image without a second thought, consider your options and identify what seems to be the best compromise – it will most likely save you some headaches down the line.Īlso remember that, beyond sheer size considerations, the smaller the image, the smaller the potential attack surface. Although nothing is ever set in stone and you can always change the base image later, the more complex a Dockerfile, the more painful it can get to port it to a different Linux distribution. So how to pick the right version of an image? A good approach would be to start with the most minimal available version and move up the footprint ladder in case of lack of dependency support only. Unless you are well versed in system administration, you probably don't want to go there. Alpine is great as long as what you need is available from the official package repository (which is well-stocked, to be fair, unlike bathroom hygiene aisles at the moment), but if something is missing you might be in for some fun in order to add it manually. The total size of our images now amounts to around 700 MB, which is less than half the initial weight.Īnd, as a bonus, you can now access phpMyAdmin at phpmyadmin.test, instead of localhost:8080.Īs often, however, there is no silver bullet. Run the now familiar docker compose up -d again, followed by docker compose images: We are now ready to test out our new setup. The reason is that at the time of writing, there is simply no available Alpine version for the MySQL image, for reasons laid out in this GitHub issue. That leaves us with the MySQL service, which hasn't changed at all. ![]() Just like Nginx, the only difference is we appended -alpine at the end of the image tag to get the Alpine-based version instead. docker/nginx/conf.d, alongside php.conf:įROM php:8.1-fpm-alpine RUN docker-php-ext-install pdo_mysql I also sometimes find it helpful to have a look at the image's Dockerfile, as it is easier to use an image once we understand how it is built.Īs a result, we need an Nginx configuration for phpMyAdmin. This is a good example of where to find help whenever official documentations fall short: browsing GitHub issues is usually a good place to start, as someone is likely to have stumbled upon the same problem before. Where to find help? Using an external HTTP server for phpMyAdmin is actually not documented, and I had to dig up some GitHub issue to put me on the right track. As its name suggests, the 5-fpm-alpine tag is the Alpine-based version of the image, whose container runs PHP-FPM as a process and expects PHP files to be handled by an external HTTP server. The reason is that Nginx will now be serving phpMyAdmin as well as our PHP application, where previously the phpMyAdmin image featured its own HTTP server (Apache). We also mounted a new named volume phpmyadmindata (declared at the bottom of the file) and used depends_on to indicate that the phpMyAdmin container should be started first. On the Nginx side, we simply appended -alpine to the image tag, to pull the Alpine-based version (remember that the available versions of an image are listed on Docker Hub). Image: phpmyadmin/phpmyadmin:5-fpm-alpine Test: mysqladmin ping -h 127.0.0.1 -u root -password=$$MYSQL_ROOT_PASSWORD Replace the content of docker-compose.yml with this one (changes have been highlighted in bold): ![]() This command will stop and/or destroy the containers, as well as remove the volumes and images, allowing us to start afresh. $ docker compose down -v -rmi all -remove-orphans ![]() The dockerised version of Alpine is as small as 4 MB, and most official Docker images provide a version based on this distribution.īefore we modify our setup, let's get rid of the current one: Is there anything we can do about it? Alpine LinuxĪlpine is a Linux distribution that takes the opposite approach: focused on security and with a small footprint, it features the bare minimum by default and lets you install what you actually need for your application. In turn, this has an impact on performance, security and, sometimes, the cost of deployment. On the other hand, Docker containers are supposed to run a single process, meaning what they need to perform their jobs usually doesn't amount to much, and is unlikely to change over time.īy using standard Linux distributions, we embark a lot of tools and services we don't always need, unnecessarily increasing the size of the images in the process. Most Linux distributions come with many services that are expected to cover common use cases they offer a large amount of programs, intended to address a broad audience whose needs may evolve over time. The total amounts to roughly 1.5 GB, which is not light. It will display a table containing the images used by the application and some information about them, including their weight:
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |