10 ms·

In sum, zero benefits from using containers. Still have to decide on a single OS to reduce maintenance problems. Could just have installed all the services (wh

by gcb0 8y ago

In sum, zero benefits from using containers. Still have to decide on a single OS to reduce maintenance problems. Could just have installed all the services (which are all available as packages) and handled the configuration files instead of configuration files+docker file+s3 costs of docker image with nothing but the base os + one package and a configuration file.

adtac 8y ago
>configuration files+docker file Dockerfiles are a part of the configuration >s3 costs of docker image Just like how most programs are available as packages in your favourite distribution's package manager, most programs are available as Docker images on Docker hub, which is as gratis as packages built for distros. And for the ones that don't have an image on Docker hub, you can include the Dockerfile to build it on the spot in the production environment. The real benefit comes from having the _ability_ to use a different base distribution if required. While alpine is suitable for most applications, sometimes you might be required to run a different distro; perhaps you're packaging a proprietary application compiled for Glibc. Also, networking isolation is straightforward in Docker. Let's say there's a serious security bug in Postgres that allows you to log in without any password. If someone could perform a RCE in a public-facing website, this would be a catastrophe as they'd be able to exploit the database server as well. With Docker, you can easily put each service in its own network and only give access to the database network to those services that need it. Or you can be even more paranoid and have a separate database and a separate network for each service. One more feature I'm fan of is the ability to run multiple versions of a software. Maybe some applications require Postgres 9.x and some require Postgres 10.x. No problem, run both in separate containers. You can't do that with regular distributions and package managers (at least in any I know of).
- paulddraper 8y ago
  > You can't do that with regular distributions and package managers (at least in any I know of). Nix would be your best shot at that outside Docker.
  - chriswarbo 8y ago
    Guix "pack" comes to mind https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pack.html https://www.gnu.org/software/guix/manual/en/html_node/Invoki... Guix is like Nix, but I don't think Nix has an equivalent command to bundle a bunch of packages into a self-contained file for running on arbitrary distros (without Nix/Guix installed).
  - weberc2 8y ago
    Nix is... tough. I really want to like it, but every time I pick it up I end up having to write some custom package definition for some obscure transitive C dependency with its own snowflake build system. Couple that with poor documentation for existing packages, the terrible search engine experience ("Nix" and "Nix packages" usually turn up things about Unix or "Congress Nixes Aid Package"), and a thousand other papercuts and it just seems to create more problems than it solves. I dearly hope this changes.
    - paulddraper 8y ago
      Yeah, in its current state Nix isn't easy to pick up and use, like say, Docker.
- snaky 8y ago
  > put each service in its own network cgroups and network namespaces. > run multiple versions of a software https://devmanual.gentoo.org/general-concepts/slotting/index.html https://devmanual.gentoo.org/general-concepts/slotting/index...
  - triplewipeass 8y ago
    Anyone building out a setup based on cgroups and namespaces will eventually arrive at a poorly specified, bug ridden mini Docker. Might as well get with the program early.
    - snaky 8y ago
      Anyone calling bc from bash script will eventually arrive at a poorly specified, bug ridden mini Mathematica? Wrt "bug ridden" > if I were having trouble with something Docker-related I would honestly feel like there was a 50/50 chance between it being my fault or a Docker bug/limitation https://blog.abevoelker.com/why-i-dont-use-docker-much-anymore/ https://blog.abevoelker.com/why-i-dont-use-docker-much-anymo...
  - Svenstaro 8y ago
    That's a bit like saying "ORMs are too complex" before proceeding to eventually build your own crappy ORM. I think by accepting docker you gain a lot of support from a developer community which you'd otherwise not see if you assembled your own.
    - snaky 8y ago
      Before proceeding to eventually learn the modern SQL finally and write a couple of stored procedures to stop pumping terabytes of almost-raw data to your "application server" code to be filtered by ORM that is too complex to understand, and in the same time still too stupid to use half of the features your DBMS provides.
      - geezerjay 8y ago
wyqydsyq 8y ago
Sounds like you don't understand Docker or containerisation in general > Still have to decide on a single OS to reduce maintenance problems. No you don't, you can run various distros in docker containers. We're using a mix of Debian (to run legacy services developed to run on old Debian LAMP servers) and Alpine (for our sexy new microservices) at my current job. > Could just have installed all the services (which are all available as packages) and handled the configuration files Then you would have a system dependent on the volatile state you configured by hand, meaning the system configuration is not declarative or reproducible.
- shittyadmin 8y ago
  > Then you would have a system dependent on the volatile state you configured by hand, meaning the system configuration is not declarative or reproducible. If you're using Ansible as the author already was, you essentially have this already. I can do a one command deploy to cloud servers, dedicated servers and colo boxes with just Ansible. Docker gets you a slightly more guaranteed environment and an additional layer of abstraction (which has its own set of pros and cons), but that's about it.
  - johncolanduoni 8y ago
    Slightly more guaranteed is something of an understatement; if you specify base images with specific hashes and pin package versions, you can get quite close to reproducible builds of the environment.
    - alias_neo 8y ago
      In support of your argument; Look for example at the Dockerfile for the official Golang container. They pin exact sha256 hashes for each architecture, and the source release in case you're on an un-binary-released architecture. Pin specific versions of your packages, coupled with caching and you're sitting pretty.
    - shittyadmin 8y ago
      Yes, but you still can't guarantee anything about the host the docker container has to run on, so you're still impacted by host configuration and therefore still need to provide a good base environment for running your containers. This is fairly simple with most providers, but in such a case, using Ansible or similar to deploy directly to the host has similar results.
ascar 8y ago
> s3 costs of docker image with nothing but the base os An alpine container is in the middle double digit MB range and will be reused in all other images using it. The space costs are trivial. Furthermore the base image is hosted on Dockerhub and last I checked you can host up to 3 images privately on Dockerhub and unlimited in public.
Jureko 8y ago
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 easily portable. If his server goes down, or he just decides to move, OP can now deploy all of his websites onto another server instantly. He also quotes the ability to build (and test) locally before shipping images to production, which is a really neat workflow. Improved security comes as an added bonus. As for the "s3 costs of docker image", it's a few cents per month.
- 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.
IloveHN84 8y ago
Clearly you don't understand the advantage of containers. You can swap them without causing problems to other services, in contrast with traditional installation on a single OS.
radiator 8y ago
It is a surprise, since he was already a FreeBSD user, that he did not use its facilities like for example jails + perhaps a program to manage them or bhyve for VMs.
- StreamBright 8y ago
  Jails do not have the same feature set. Orchestration is still need to be managed somehow.
  - tachion 8y ago
    Which features Jails are missing? You have to orchestrate Docker just as you have to orchestrate Jails, there is a reason why Kubernetes is on the rise.
    - StreamBright 8y ago
      Docker offers orchestration out of the box.
StreamBright 8y ago
The only question is how to have Docker Compose like functionality without Docker.
pgt 8y ago
The killer feature of containers is immutability at the file-system level, not scale.
kstenerud 8y ago
He's taken the first level step of containerization. What he gets is a deterministic way to build his environment. You could just install the services and handle the configuration files, but then you suffer from replicability and deterministic build problems: - The configuration files are all over the place, and while you can remember most of them, you can't be 100% sure that you got everything in /var/lib/blahblah/.config/something.conf, /etc/defaults/blahblah, /etc/someotherthingd/blahblah.conf, etc. - Rebuilding the server becomes a problem because you don't remember a year and a half later everything you did to set the damn thing up. Even worse, you've been tweaking your config over time, installing other packages that you can't remember, putting in custom scripts for various things... - Recovering from a catastrophic failure is even worse, because now you don't even have the old configuration to puzzle through. - If you set up another failover system, you can't be sure it's configured 100% the same as the old one. And even if you did get them 100% the same, they WILL drift over time as you forget to migrate changes from one to the other. You can mitigate this by using ansible or chef or docker or the like. The other handy thing with container tech is that you can tear down and rebuild without having to wipe your hard drive and spend 30 minutes reinstalling the OS from the iso. Iterating your builds until you have the perfect setup becomes a lot more appealing when your turnaround time is 2-5 minutes. Damage control becomes a lot easier. A bug in one program doesn't damage something in another container. After this level, you can move up to the orchestration layer, where each container is just a component, and you tell your orchestration layer to "launch two of these with failover and the following address, link them to instances of postgresql, do an nginx frontend with this cache and config, pointing to this NAS for data", and it just works. It's a lot like programming languages. You COULD do it all in assembly, but C is nicer. You COULD do it all in C, but for most people, a gc functional language with lambdas and coroutines etc gives you the sweet spot between cognitive load and performance. With a shared language for doing these powerful things, you now gain the ability to easily share with others (like docker hub), increasing everyone's power exponentially. Yes, you need to vet whose components you are using, but that's far less work than building the world yourself. Yes, there's a learning curve, but the payoff over time from the resulting power of expression is huge.
mamcx 8y ago
The problem that docker solve for me is reinstalling. Some software, like RDBMS, are heavy to setup. You can do once and is not that hard, but then when the day come to reinstall, upgrade or move it to another version: - You need to remember how do that - If you upgrade OS, the step have changed - If the install (of the OS) go kaput, you can lose the work of setup everything so far -the steps- (ie: I have a few times manage to ruin some ubuntu install. Instead of wasting time fixing it, I spin another server and redo) - If the install (of the app) go kaput, you are left with a inconsistent state (I manage to broke a PG database in a upgrade, because was looking to the wrong tutorial, Instead of wasting time fixing it, I spin another docker image and redo from backup) - I try to upgrade everything fast. A new ubuntu version? upgrade. A new major PG version? upgrade. Not always to production but I don't like to wake up 2 years late and face a BIG upgrading cycle. prefer to spread the pain in the year. If something wanna break, I want to see it coming. So I reinstall a lot of times. And it work across OS. So all the problems of above, was in my dev machine! P.D: I wanna something alike docker, I don't care for orchestration (so far) only something that allow to package apps/dependencies, work in my small serves, allow to (re)build as fast as possible. What other option can work? (P.D: My main deps are postgress, nginx, redis, python3, .net core, rust (coming). Wish to setup android/ios toolchains too)
auslander 8y ago
> In sum, zero benefits from using containers. Agree. Especially in native cloud, like AWS, where you already took care of host deaths, scalability, making data persistent, aka good automation.

by gcb0 8y ago

adtac 8y ago

>configuration files+docker file Dockerfiles are a part of the configuration >s3 costs of docker image Just like how most programs are available as packages in your favourite distribution's package manager, most programs are available as Docker images on Docker hub, which is as gratis as packages built for distros. And for the ones that don't have an image on Docker hub, you can include the Dockerfile to build it on the spot in the production environment. The real benefit comes from having the _ability_ to use a different base distribution if required. While alpine is suitable for most applications, sometimes you might be required to run a different distro; perhaps you're packaging a proprietary application compiled for Glibc. Also, networking isolation is straightforward in Docker. Let's say there's a serious security bug in Postgres that allows you to log in without any password. If someone could perform a RCE in a public-facing website, this would be a catastrophe as they'd be able to exploit the database server as well. With Docker, you can easily put each service in its own network and only give access to the database network to those services that need it. Or you can be even more paranoid and have a separate database and a separate network for each service. One more feature I'm fan of is the ability to run multiple versions of a software. Maybe some applications require Postgres 9.x and some require Postgres 10.x. No problem, run both in separate containers. You can't do that with regular distributions and package managers (at least in any I know of).

paulddraper 8y ago
> You can't do that with regular distributions and package managers (at least in any I know of). Nix would be your best shot at that outside Docker.
- chriswarbo 8y ago
  Guix "pack" comes to mind https://www.gnu.org/software/guix/manual/en/html_node/Invoking-guix-pack.html https://www.gnu.org/software/guix/manual/en/html_node/Invoki... Guix is like Nix, but I don't think Nix has an equivalent command to bundle a bunch of packages into a self-contained file for running on arbitrary distros (without Nix/Guix installed).
- weberc2 8y ago
  Nix is... tough. I really want to like it, but every time I pick it up I end up having to write some custom package definition for some obscure transitive C dependency with its own snowflake build system. Couple that with poor documentation for existing packages, the terrible search engine experience ("Nix" and "Nix packages" usually turn up things about Unix or "Congress Nixes Aid Package"), and a thousand other papercuts and it just seems to create more problems than it solves. I dearly hope this changes.
  - paulddraper 8y ago
    Yeah, in its current state Nix isn't easy to pick up and use, like say, Docker.
snaky 8y ago
> put each service in its own network cgroups and network namespaces. > run multiple versions of a software https://devmanual.gentoo.org/general-concepts/slotting/index.html https://devmanual.gentoo.org/general-concepts/slotting/index...
- triplewipeass 8y ago
  Anyone building out a setup based on cgroups and namespaces will eventually arrive at a poorly specified, bug ridden mini Docker. Might as well get with the program early.
  - snaky 8y ago
    Anyone calling bc from bash script will eventually arrive at a poorly specified, bug ridden mini Mathematica? Wrt "bug ridden" > if I were having trouble with something Docker-related I would honestly feel like there was a 50/50 chance between it being my fault or a Docker bug/limitation https://blog.abevoelker.com/why-i-dont-use-docker-much-anymore/ https://blog.abevoelker.com/why-i-dont-use-docker-much-anymo...
- Svenstaro 8y ago
  That's a bit like saying "ORMs are too complex" before proceeding to eventually build your own crappy ORM. I think by accepting docker you gain a lot of support from a developer community which you'd otherwise not see if you assembled your own.
  - snaky 8y ago
    Before proceeding to eventually learn the modern SQL finally and write a couple of stored procedures to stop pumping terabytes of almost-raw data to your "application server" code to be filtered by ORM that is too complex to understand, and in the same time still too stupid to use half of the features your DBMS provides.
    - geezerjay 8y ago

wyqydsyq 8y ago

Sounds like you don't understand Docker or containerisation in general > Still have to decide on a single OS to reduce maintenance problems. No you don't, you can run various distros in docker containers. We're using a mix of Debian (to run legacy services developed to run on old Debian LAMP servers) and Alpine (for our sexy new microservices) at my current job. > Could just have installed all the services (which are all available as packages) and handled the configuration files Then you would have a system dependent on the volatile state you configured by hand, meaning the system configuration is not declarative or reproducible.

shittyadmin 8y ago
> Then you would have a system dependent on the volatile state you configured by hand, meaning the system configuration is not declarative or reproducible. If you're using Ansible as the author already was, you essentially have this already. I can do a one command deploy to cloud servers, dedicated servers and colo boxes with just Ansible. Docker gets you a slightly more guaranteed environment and an additional layer of abstraction (which has its own set of pros and cons), but that's about it.
- johncolanduoni 8y ago
  Slightly more guaranteed is something of an understatement; if you specify base images with specific hashes and pin package versions, you can get quite close to reproducible builds of the environment.
  - alias_neo 8y ago
    In support of your argument; Look for example at the Dockerfile for the official Golang container. They pin exact sha256 hashes for each architecture, and the source release in case you're on an un-binary-released architecture. Pin specific versions of your packages, coupled with caching and you're sitting pretty.
  - shittyadmin 8y ago
    Yes, but you still can't guarantee anything about the host the docker container has to run on, so you're still impacted by host configuration and therefore still need to provide a good base environment for running your containers. This is fairly simple with most providers, but in such a case, using Ansible or similar to deploy directly to the host has similar results.

ascar 8y ago

> s3 costs of docker image with nothing but the base os An alpine container is in the middle double digit MB range and will be reused in all other images using it. The space costs are trivial. Furthermore the base image is hosted on Dockerhub and last I checked you can host up to 3 images privately on Dockerhub and unlimited in public.

Jureko 8y ago

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 easily portable. If his server goes down, or he just decides to move, OP can now deploy all of his websites onto another server instantly. He also quotes the ability to build (and test) locally before shipping images to production, which is a really neat workflow. Improved security comes as an added bonus. As for the "s3 costs of docker image", it's a few cents per month.

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.

IloveHN84 8y ago

Clearly you don't understand the advantage of containers. You can swap them without causing problems to other services, in contrast with traditional installation on a single OS.

radiator 8y ago

It is a surprise, since he was already a FreeBSD user, that he did not use its facilities like for example jails + perhaps a program to manage them or bhyve for VMs.

StreamBright 8y ago
Jails do not have the same feature set. Orchestration is still need to be managed somehow.
- tachion 8y ago
  Which features Jails are missing? You have to orchestrate Docker just as you have to orchestrate Jails, there is a reason why Kubernetes is on the rise.
  - StreamBright 8y ago
    Docker offers orchestration out of the box.

StreamBright 8y ago

The only question is how to have Docker Compose like functionality without Docker.

pgt 8y ago

The killer feature of containers is immutability at the file-system level, not scale.

kstenerud 8y ago

He's taken the first level step of containerization. What he gets is a deterministic way to build his environment. You could just install the services and handle the configuration files, but then you suffer from replicability and deterministic build problems: - The configuration files are all over the place, and while you can remember most of them, you can't be 100% sure that you got everything in /var/lib/blahblah/.config/something.conf, /etc/defaults/blahblah, /etc/someotherthingd/blahblah.conf, etc. - Rebuilding the server becomes a problem because you don't remember a year and a half later everything you did to set the damn thing up. Even worse, you've been tweaking your config over time, installing other packages that you can't remember, putting in custom scripts for various things... - Recovering from a catastrophic failure is even worse, because now you don't even have the old configuration to puzzle through. - If you set up another failover system, you can't be sure it's configured 100% the same as the old one. And even if you did get them 100% the same, they WILL drift over time as you forget to migrate changes from one to the other. You can mitigate this by using ansible or chef or docker or the like. The other handy thing with container tech is that you can tear down and rebuild without having to wipe your hard drive and spend 30 minutes reinstalling the OS from the iso. Iterating your builds until you have the perfect setup becomes a lot more appealing when your turnaround time is 2-5 minutes. Damage control becomes a lot easier. A bug in one program doesn't damage something in another container. After this level, you can move up to the orchestration layer, where each container is just a component, and you tell your orchestration layer to "launch two of these with failover and the following address, link them to instances of postgresql, do an nginx frontend with this cache and config, pointing to this NAS for data", and it just works. It's a lot like programming languages. You COULD do it all in assembly, but C is nicer. You COULD do it all in C, but for most people, a gc functional language with lambdas and coroutines etc gives you the sweet spot between cognitive load and performance. With a shared language for doing these powerful things, you now gain the ability to easily share with others (like docker hub), increasing everyone's power exponentially. Yes, you need to vet whose components you are using, but that's far less work than building the world yourself. Yes, there's a learning curve, but the payoff over time from the resulting power of expression is huge.

mamcx 8y ago

The problem that docker solve for me is reinstalling. Some software, like RDBMS, are heavy to setup. You can do once and is not that hard, but then when the day come to reinstall, upgrade or move it to another version: - You need to remember how do that - If you upgrade OS, the step have changed - If the install (of the OS) go kaput, you can lose the work of setup everything so far -the steps- (ie: I have a few times manage to ruin some ubuntu install. Instead of wasting time fixing it, I spin another server and redo) - If the install (of the app) go kaput, you are left with a inconsistent state (I manage to broke a PG database in a upgrade, because was looking to the wrong tutorial, Instead of wasting time fixing it, I spin another docker image and redo from backup) - I try to upgrade everything fast. A new ubuntu version? upgrade. A new major PG version? upgrade. Not always to production but I don't like to wake up 2 years late and face a BIG upgrading cycle. prefer to spread the pain in the year. If something wanna break, I want to see it coming. So I reinstall a lot of times. And it work across OS. So all the problems of above, was in my dev machine! P.D: I wanna something alike docker, I don't care for orchestration (so far) only something that allow to package apps/dependencies, work in my small serves, allow to (re)build as fast as possible. What other option can work? (P.D: My main deps are postgress, nginx, redis, python3, .net core, rust (coming). Wish to setup android/ios toolchains too)

auslander 8y ago

> In sum, zero benefits from using containers. Agree. Especially in native cloud, like AWS, where you already took care of host deaths, scalability, making data persistent, aka good automation.