11 ms·

That's not a fair assessment and I'm surprised this is the top comment. In this case, the huge advantage to a containerized setup is that everything is now easi

• NhanH 8y ago
  Concerns about server going down or changing cloud provider imo is not particularly interesting or even useful advantage to mention for personal infrastructure. Considering that it's likely we might change our personal infrastructure less than one every year and I've never got a case when an unmaintained docker setup can run 6 months later, I'm not sure if the value for portable is that high.
  • geezerjay 8y ago
    > Concerns about server going down or changing cloud provider imo is not particularly interesting or even useful advantage to mention for personal infrastructure. Why? Personal projects aren't more stable or bound to a single provider. If anything, personal projects may benefit more from a deployment strategy that makes it quite trivial to move everything around and automatically restart a service in a way that automatically takes dependencies into account. > Considering that it's likely we might change our personal infrastructure less than one every year In my experience, personal projects tend to be more susceptible to infrastructure changes as they are used to experiment stuff. > and I've never got a case when an unmaintained docker setup can run 6 months later, The relevant point is that the system is easier to maintain when things go wrong and no one is looking or able to react in a moment's notice. It doesn't matter if you decide to shutdown a service 3 or 4 months after you launch it because that's not the usecase. > I'm not sure if the value for portable is that high. That assertion is only valid if you compare Docker and docker-compose with an alternative, which you didn't. When compared with manual deployment there is absolutely no question that Docker is by far a better deployment solution, even if we don't take into account the orchestration funtionalities.
  • josteink 8y ago
    > Concerns about server going down or changing cloud provider imo is not particularly interesting or even useful advantage to mention for personal infrastructure. I’ll let you know my kids personally disagrees with you on this one if Plex on the TV or iPad suddenly doesn’t work. Being able to easily migrate apps is super nice to when changing hardware/server.
  • ilkkao 8y ago
    I've been upgrading my OVH dedicated server once in a year. So far it has been possible to get a little bit better server for the same price from their black Friday sale. Thanks to a simple bootstrap shell script, docker and docker compose I'm able to migrate my ten random services and two KVM VMs in two hours (copying /data directory takes most of the time obviously)
  • merty 8y ago
    > Concerns about server going down or changing cloud provider imo is not particularly interesting or even useful advantage to mention for personal infrastructure. I look at this from a different perspective: I have plenty of actual things to do, personal infra should be the least of my concerns and I should be able get them up and running in least amount of time. > I've never got a case when an unmaintained docker setup can run 6 months later It really depends on the well-being of the host and the containerized application. I have plenty of containers running for more than a year without a single hiccup.
• gcb0 8y ago
  "I don't know how to monitor and restart a process. so let me wrap it into a vm and then monitor and restart it" :) there are lot of cases for containers. this isn't one (although over engineering personal projects is always fun)
  • icebraining 8y ago
    Nobody said anything about monitoring or restarting processes, and containers aren't vms.
  • weberc2 8y ago
    It's not over-engineering; it's quite a lot easier to get Docker up and running and run things in it rather than dealing with init systems, package managers (and dependency conflicts), ansible, etc for every app. You get a sane, consistent, and standard interface to logging, networking, data management (volumes), declarative infrastructure, packaging, etc and Docker swarm makes it relatively simple to scale up to multiple nodes.
• scaryclam 8y ago
  You're giving the credit of automation to docker, which isn't where the credit belongs. It's pretty easy to get the same portability and testing without containers (this is what was happening long before docker was launched). Not to say that the OP shouldnt have done it, but I'm kind of tired of seeing the whole portability thing still being put up as if it's only viable with containerised solutions.
  • gnur 8y ago
    To be fair, docker itself introduced no radical new technologies, but it did introduce a lot of convenience. Containers had been available for a long time, but the convenience of a Dockerfile + docker hub made at accessible for the non hard code linux/bsd people. What other solution for the easy portability do you know? Or how would you propose to handle this? If it is easier then docker build && docker push and docker pull on the other side I'm all ears!
    • lmm 8y ago
      > What other solution for the easy portability do you know? Or how would you propose to handle this? Puppet for the server-automation part. Languages that make it easy to produce a "fat binary" for the isolation part. Docker solves a real problem for languages where deployment is a mess, like Python. It just grates on me when the same people who spent the last 10 years mocking Java (which does essentially the useful parts of docker) are suddenly enthusiastic about the same kind of solution to the same kind of problem now that it has a trendy name.
    • e12e 8y ago
      The main benefit docker introduced, was leading developers to at least consider "configuration injection" and "stateless installs" ("12 factor apps"). If upstream supplies a decent docker image, chances are that means the package is more amenable to scripting and running in a chroot/jail/container - and documents it dependencies somewhat. That said, snaphotting the "state" of your container/jail can be nice. Recently I used the official ruby images, and could build a custom image to use with our self-hosted gitlab (with built-in docker registry) that a) got a standard Debian based ruby image and applied updates, and b) built freetds for connecting to mssql. Now I can quickly update that base image as needed, while the CI jobs testing our rails projects "only" need a "bundle install" before running tests. And the scripts are largely reusable across heterogeneous ruby versions (yes I hope we can get all projects up on a recent ruby..).
• blablabla123 8y ago
  Yeah but you can also use Ansible or a comparable tool. Moving with that is equally easy. Also without always rising storage usage that results from configuration tweaking, which can be especially problematic if you deploy heavy-weight Java servers.
• TicklishTiger 8y ago
  OP can now deploy all of his websites onto another server instantly By running the docker specific setup files he describes in his post? He could have just written a setup script that installs the needed services on any machine. Without adding all that docker specific complexity described in the post: Moving to Alpine Building his own Alpine image Building 9 more Docker images Orchastrate all the docker images Sign up for Amazons container registry Now additionally to the host OS, he has to maintain 10 frickin docker images. Seems totally insane to me.
  • geezerjay 8y ago
    > Without adding all that docker specific complexity described in the post: My guess is that you never used containers at all, let alone Docker. A Dockerfile is just a setup script that installs the needed services on an image, which you can run on any machine. That's it. There is no added complexity.
    • TicklishTiger 8y ago
      You guessed wrong. This is not about a single Docker file vs a setup script. If you read my post you will see that I describe the steps the author took. And they are plenty. My guess is that you did not read the article at all. He was "building Docker images for each of the services". So not a single one. 10 of them. And he signed up for a commercial registry to host them. An additional service he depends on now. Yet even a single Docker file would not be as simple as a setup script. A setup script on the host OS would install some packages that the host OS will keep up to date. Using a Docker image instead puts the burden on you to keep it up to date.
      • geezerjay 8y ago
        > He was "building Docker images for each of the services". So not a single one. 10 of them. 10 services, 10 installers, 10 installations. Where exactly do you see any problem or issue? > even a single Docker file would not be as simple as a setup script. A setup script on the host OS would install some packages that the host OS will keep up to date. Using a Docker image instead puts the burden on you to keep it up to date. That's simply wrong on many levels. Yes, a single Dockerfile is as simple (if not simpler) than a setup script. A Dockerfile is a setup script. And yes, you can update individual containers or even build updated images. Again, you seem to be commenting on stuff you know nothing about.
• tannhaeuser 8y ago
  But he had to migrate away from FreeBSD to use Docker, so that doesn't sound like a portability advantage at all, in the usual sense of the word "portability". "Improved security" is also a red herring. You can't make something more secure by adding an additional layer of abstraction. He even mentions that he found it problematic that inside the Docker container, everything runs as root by default. Plus the dicker daemon must needlessly run as root on the host.
  • viraptor 8y ago
    > he found it problematic that inside the Docker container, everything runs as root by default That's technically right, but not what you'd expect. Docker runs root in a few restricted namespaces and behind seccomp by default. The syscall exploits people are worried about are often simply not available. Even then it's easy to take it another step and create new users. You could even have root mapped to a different user on the outside if you prefer that. That shouldn't be an issue if you're coming from FreeBSD - https://www.freebsd.org/doc/en/articles/new-users/adding-a-user.html https://www.freebsd.org/doc/en/articles/new-users/adding-a-u... > If you did not create any users when you installed the system and are thus logged in as root, you should probably create a user now with ...
  • rsync 8y ago
    ""Improved security" is also a red herring. You can't make something more secure by adding an additional layer of abstraction." I have not used docker. However, I have been putting things in containers with FreeBSD 'jail' since 2001 ... If I jail my httpd and there is a vuln in the httpd, the attacker gets the jail (and the httpd, etc.) but not the underlying system. That's a huge win, in my mind - is that not how it works in dockerland ?
    • weberc2 8y ago
      Last I checked, Docker containers are not hard to break out of unless you go to extra lengths (SELinux, AppArmor, etc--not entirely sure; I'm not an expert). Most people use Docker as a way to avoid their programs accessing the wrong version of a shared dependency or similar. I believe there may be other container runtimes with stronger guarantees or better defaults, some of which are even suitable for running untrusted code (or so they advertise).
• cm2187 8y ago
  You can achieve that with a lot less headaches with simple Virtual Machines. Also makes backup more trivial (simply copy a file).
  • weberc2 8y ago
    I would disagree with this even if I had a really nice cloud operator with great interfaces and utilities for logging, networking, monitoring, image management, volume management, secrets management, declarative infrastructure, etc and you can afford to run that many VMs... I'd still probably be running lots of cruft (SSH servers, process managers, etc) in each VM (or I'd have to go through the trouble of opting out) and I still need to get logs out of the VM and into the logging service, which usually implies faffing with ansible and friends. Nooooo thank you. Also, `docker commit` is pretty easy, and you can also just back up individual volumes.
  • moosingin3space 8y ago
    I disagree -- with traditional VMs, you have to deal with multiple mutable systems. In the Docker/OCI container world, containers are immutable, so you can manage all your changes atomically, from a single source of truth (your Dockerfile collection).
    • indigodaddy 8y ago
      In my view, LXD/LXC splits the difference pretty nicely between VMs and Docker. Portability with LXD is even cleaner as all the data is in the lxc container. It's not immutable, and the initial setup is a little more involved as you have to set up services on each container, eg no dockerfiles, and you need to figure out ingress on the host often less declaratively, with normally routing 80/443 via iptables to an nginx or haproxy container to then reverse proxy to the relevant container per domain-based ACLs.... etc. But, I still prefer it to Docker. I rather don't mind initially setting up and configuring the needed services the first time on each container... And for me that's a good way to get familiar with unfamiliar packages and services/applications that I might want to try/play with, rather than just go find a dockerfile for Application X or Y and not actually learn that much about the service or application I am deploying. Speaking for myself only-- obviously there are the gurus who know common services and applications inside and out already, and can configure them blindfolded, so Dockerfile everything would make sense for them. To each his/her own.
• mrighele 8y ago
  The advantage is not that huge if you compare to the author's previous setup, which was based on Ansible. Unless you like to run a different OS per virtual machine, moving your websites to a new machine (or add a new machine to the bunch) is as easy as with Docker, and you can test your setup locally too (though you will need a VM running on your computer). The biggest advantage of Docker in my opinion is that it makes it much easier to make conflicting software coexist on the same machine (for example two websites requiring two different versions of node.js or php). Also it is nice that you can build the image once and then deploy it many times. Ansible's equivalent is of rebuilding the image every time you want to deploy it. Also I find it a bit easier to accomplish what I want with a Dockerfile than with an Ansible script and if you make some mistakes it is easier to rebuild an image than "cleanup" a VM instance. So, Docker smooths many edges compared to Ansible, but I wouldn't consider that a _huge_ advantage, expecially in the context of a personal infrastructure.
  • pmontra 8y ago
    Another advantage is that you can run more up to date packages than your distro would allow, or different versions of the same one. The downside is that you should rebuild the containers daily to be sure to have all the security patches. Not as convenient as apt-get. Maybe it's more cost effective to run another VPS or two.
• muppetman 8y ago
  Sure the containers he can just re-setup, but what about all the DATA. Where is all the data for his mattermost instances being held? You still have to back that up somehow/somewhere and feed it into your "new containers" that are on another server "instantly"