![]() ![]() Our new architecture, running Nginx and PHP-FPM, is providing very noticeable performance improvements. Performance improvementsĭocker gives us no performance improvements whatsoever, but it doesn't penalize us either. ![]() And we're able to easily run different versions of PHP on the same server. With Docker, we take this one step further: we mount the web root into the Docker container as a read-only volume - so even if an attacker somehow gained root through the PHP interpreter itself, the attacker still cannot plant their executable code into the site.Ī couple other big wins here: we support a few "legacy" installations of older Drupal and some non-Drupal sites - we're now able to contain and isolate those from other sites on the same server, so a compromise on one site cannot hop over and infect another site. In our former LAMP setup, we would use filesystem permissions to prevent the Apache web user from being able to write to the filesystem, anywhere other than the directories with assets Drupal manages on the disk (images, videos, aggregated CSS/JS, etc) and prevent execution in the directories where Drupal can write. So the first place to secure is the executable environment - PHP itself. And the vast majority of attacked websites we see (5 so far this year) plant a malicious script in an executable environment and run it. That said, I'm reasonably confident that Linux containers do an effective job of isolating processes running inside them to just what's visible to those processes. It is early enough days that I'm not entirely confident somebody gaining a shell on the host couldn't somehow attack the Docker process itself to gain root access and modify whatever they want on the host. For example, adding somebody to the "docker" group is quite effectively giving them full root access to the entire host. Our philosophy on production Docker use is that containers are ephemeral - they get destroyed and recreated all the time, and so there should not be anything in the container we care about losing.ĭocker is still a pretty young technology, and it clearly opens up some new avenues of attack, which need to be carefully considered. Inside each container that might need to send email, we've added/configured SSMTP and pointed it at the host.Īlso on the host: all data, databases, deployment tools (git, drush, composer, etc), cron jobs (using drush for Drupal cron). We also run a local Postfix instance on the host that relays mail to our mail server. We didn't end up solving this - we just removed the wildcard DNS entry and then everything worked fine. We ran into problems having a wildcard DNS entry set up (*.) when the hostname was part of that domain - most requests for a hostname that was not fully-qualified resolved the wildcard DNS entry instead of the local DNSMasq entry.There is a lag before the host DNSmasq populates new container addresses - we currently have an update script that polls every 10 seconds for new changes, and Nginx needs a reload to see a change in a container IP address.There are a couple gotchas with this approach: Using this pattern, we can link all the containers together by a simple hostname, without having to link specific containers together. We configure DNSMasq on the host so that you can reach any container on the host by its name, and set each container to use the host's DNS. When using Docker, each container has a different IP address bridged on the host, and can expose different TCP ports, or sockets in the filesystem, to allow connections. On our production servers, we have kept Nginx, Postfix, and DNSMasq outside the containers and installed directly on the host. So far we have put PHP, MariaDB, Apache Solr, and a bunch of other supporting services into containers. So the best practices are to have a different container for each necessary service, not a single container with the whole set. You might think of Linux containers as a form of "cheap virtualization." However, the way the Docker community has come to use them is more like a chroot jail - a way of isolating a single process into a container that protects the rest of the system if that process gets compromised, and not a full operating system with multiple processes. Docker is a system for managing Linux containers. If you're a technical person and haven't heard of Docker, you must have been offline for a couple years. We still use Linux, MariaDB and PHP, of course, but instead of Apache we've moved to Nginx, and we've added Docker and Salt. This year we're replacing our old "traditional" LAMP stack with an entirely less pronounceable LNDMPS version. Three nice benefits we get from our new standard Drupal server architecture. ![]()
0 Comments
Leave a Reply. |