skip to Main Content

I’m facing a migration from old dedicated server to one with newer hardware. Currently I’m hosting following websites:

  • PHP + nginx + mysql
  • PHP + nginx + postgresql
  • (venv) Flask + nginx + redis
  • (venv) django + nginx + memcached + postgres

all of the websites are working flawlessy. Currently I’m thinking about packing them into containers, but what would be the benefits of containerization? The pros are quite obvious if I use Docker during the development, but what about old setups? I did some googling, however I couldn’t find any answer from experienced devs.

2

Answers


  1. I have tried to avoid opinion here, and just state the facts of my experience, however the very nature of the question does, of course, invite uncertainty and debate.

    I have recently finished a migration to docker.

    Main advantages:

    • Enforcing stateless thinking
    • Scaling
    • Ease of deployment
    • Identical development environment (*massive caveat – see below)

    Main disadvantages:

    • Learning curve
    • Abstraction of environment

    First things first:

    If your services are heavily stateful (on the filesystem) you are going to have to re-architect quite hard, or lose almost all of the advantages of Docker. If this is the case I would emphatically tell you not to bother at this stage, and perhaps see Docker as a medium-to-long term part of a wider project moving towards the 12-factor app. (https://12factor.net/)

    Even if your underlying architecture is ready for the migration, the advantages are heavily outweighed by the learning curve disadvantage if your site is never going to be ‘huge.’ Horizontal scaling is great, but most sites are never going to need it, and the time lost to the curve could, in most cases, be much more usefully employed decreasing time to market/iteration period. I am pretty confident with computers and new technology, and this took me 4 pretty solid months for a similar looking stack to yours.

    Development caveat:

    The ‘development’ advantage is fraught with danger, especially if you’re on a Mac. PHP requires many files working in tandem to run your site, and differences in the file system means this is 4 or 5 times slower on your mac (when running docker) than it will be on your server. This gets very frustrating. There are solutions, but they add to the learning curve and are still not perfect.

    Additionally, the ‘dream’ of identical environments also has many nightmarish aspects. Are you going to enforce local machines to use SSL? Then you’re going to need ‘fake’ self-signed certificates on all your dev computers, and thus complaints from browsers every time you try to visit it. Also, NGINX runs differently with docker-compose than it does with a stack deploy, and there are many advantages to developing with compose, rather than a stack, so just using stack isn’t really an option. It took me a week to figure out a solution to that.

    Once these problems have been fixed, however (we moved to Linux for development, and have scripts to solve most other problems, and just have to live with telling Chrome to accept my ‘fake’ certificates every 2 hours or so) it is, admittedly, all very smooth and I am glad I have had this experience. New projects will probably take advantage of docker from the outset now that I have a feeling for how it works, where the pitfalls are, and how to go about fixing things.

    Conclusion:

    I would advise learning docker over a year or so in your spare time, rather than committing to it at work. There are advantage now that we have gone through the pain, but it was a LOT of pain. And if you do learn it out of hours, make sure you do something that emulates a full scale production deployment, with Continuous Integration, testing, the works. Docker is so easy to get started with that it will trick you into thinking that it is equally easy to master. It really is not.

    Login or Signup to reply.
  2. Simply put, vm is a full OS with lots of stuff you don’t need while containers are literally a container for whatever service(s)(usually one service per container) you need. Because of this, it’s easier to scale. Other benefits come with this main one.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search