10 ms·

I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some t

by dancek 10y ago

I agree that containers (both for shipping and servers) are a great idea. And because I'm tired of always configuring servers, I decided to give it a try some time ago. I wrapped my IRC client (weechat + glowing-bear) in a Docker container. Oh, not a container though, because I also needed https, which meant I needed either a mechanism to build and update letsencrypt certs in the weird format that weechat expects, or to run an nginx instance in the front (and also somehow get the certs, but that's easier with nginx). So two containers. And even though there was a ready-made nginx+letsencrypt https reverse proxy container (actually several), I had a huge amount of headaches to get it actually working. Even with the system set up, I occasionally have the container crash with exit status 137 (IIRC), which I've assumed might be because weechat leaks/consumes memory and eventually the host server kernel kills the process. Maybe. So in my limited experience, comparing Docker containers to shipping containers is a gross simplification. Shipping containers are simple constructions requiring well-defined simple maintenance, while Docker containers seem to be complex thingamabobs that have multiple points of failure.

hvidgaard 10y ago
I wanted to write about my experience with containers. It mimics yours. The idea of a container is beautiful and elegant. The execution, not so much. I'm more or less convinced that to reduce this complexity, we need a limited scope ecosystem. Microsofts .Net would probably be a good place to start, but MS, being enterprise, have a habit of turning things into a mess of configuration.
chewchew 10y ago
Docker gives you the building blocks, but that means you have more pieces to arrange and manage. Take a look at Docker Compose if you haven't already, since the Docker CLI only gets you so far when you're creating apps that consist of multiple containers. I think the best approach for your cert issue is to abstract that into a separate service (nginx is an option, but I'd recommend the Rancher approach below). Yes, that means you have to add another container, but that's just another block in your docker-compose.yml file. Embrace the approach of separating your components into containers and organizing them as a stack. You can easily link containers together, share data volumes, and start/stop individual containers or the stack as a whole. The problems that you're having are pretty easy to fix with some tooling. Rancher (http://rancher.com/ http://rancher.com/) greatly simplifies the cert issue by allowing you to import certs and provide them to the Rancher loadbalancer service (which you can add to any stack). There's also a LetsEncrypt community catalog template that automatically retrieves and imports certificates to Rancher. There are other open source orchestrators like DCOS, but Rancher is probably the simplest to use, and it's the only one I'm very familiar with. There are SaaS options that you can look into, but I don't have experience with them. As for the container crashes, it's trivial to automatically restart them. Just pass the --restart=always flag to the Docker run command. You can also add the flag to a docker-compose.yml file.
- beachstartup 10y ago
  > but that means you have more pieces to arrange and manage wait. aren't these things supposed to give us less pieces to arrange and manage? > The problems that you're having are pretty easy to fix with some tooling yes, of course the solution is more tools. what exactly was the problem again?
  - chewchew 10y ago
    > wait. aren't these things supposed to give us less pieces to arrange and manage? No, not fewer pieces. You'll have more pieces, but you can combine the pieces and control them individually or as a group. You can think of Legos, since you have many pieces but they all fit together in the same way. Docker compose lets you group these containers together, and that is what ultimately makes it feel like you have fewer pieces to manage. With that, you can start/stop a stack of containers (e.g. django, nginx, postgres, redis) with a single command, but still inspect and manage each component separately. This is something you might normally do with bash scripts, but with Docker you can take that same app to an orchestration platform and run it on any host. Run it on your laptop, run it on a linux server, run it on a SaaS provider like Docker Cloud, run it on a private cloud with an orchestration platform. > yes, of course the solution is more tools. what exactly was the problem again? Docker is just the foundation. Nothing more. I'm fine with learning more tools because I feel that the foundation is solid. The problem is being able to ship and manage your apps. That is much, much easier for me now and I'm very glad I invested the time.
  - pm90 10y ago
    Its somewhat akin to microservices, where you split each functionality into its own service rather than having one monolith do everything.
- dancek 10y ago
  Thanks, I'll have to look into Rancher. I'm already using Docker-compose. Also good to know about automatic restarts. I don't know how I missed that, I had to read a lot of docs to get where I am. Still, the amount of tooling that exists and the knowledge needed to pick the right ones for a given situation goes to show that this isn't as simple as packing a shipping container and letting someone ship it...
jbverschoor 10y ago
Same here with docker. The ideas are nice as an application, but it's just a pain in the ass. LXC on the other hand is a breeze.
- dancek 10y ago
  Does LXC provide a way to automatically create new working instances (like a Dockerfile / docker-compose.yml)? I'm not quite grokking LXC in my first 10 minutes of reading...
  - gautamdivgi 10y ago
    I think you could create your own lxc template and then create new instances. The other way would be to just clone existing working instances with overlayfs. Base lxc may be a bit of a pain. Look at lxd - I believe that makes things much much simpler. Another thing about lxc is the unpriviledged container - which I think is great for security (not sure if docker provides this).
  - contingencies 10y ago
    man lxc.conf ... this is your dockerfile equivalent.
- sergiosgc 10y ago
  LXC is nice, as a building block, but it is far from "a breeze". It is refreshing, however, being able to write, in a couple of hours, a setup script from scratch that debootstraps an install, chroots in there to configure it and launches the container via systemd-nspawn. Very few moving parts, excellent for development environments. Not yet something I trust in production, though.
nikcub 10y ago
You might have better luck with container specific reverse-proxy like Traefik[0] - it has builtin Let's Encrypt support with auto-renewal > I had a huge amount of headaches to get it actually working. Moving from running one container to running multiple containers is probably one of the most confusing parts of getting started with Docker There are a large array of orchestration options and tools - each with their own pros and cons: Swarm, Kubernetes, Mesos, Marathon, Mesosphere, Centurion, Rancher, etc. Docker 1.12 now having built-in orchestration with Swarm should make this easier[1]. [0] https://github.com/containous/traefik https://github.com/containous/traefik [1] https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/ https://blog.docker.com/2016/06/docker-1-12-built-in-orchest...
- dancek 10y ago
  Traefik sounds great! I'm using https://github.com/SteveLTN/https-portal https://github.com/SteveLTN/https-portal which is a Docker container, and that kind of setup is just complicated. Putting the reverse proxy outside sounds much cleaner.
nvarsj 10y ago
Docker is a poorly engineered and over-hyped technology. The concept is great - and in fact, many companies have built great tooling around Linux cgroups. It lets you efficiently binpack applications on a single server - which is why 'containers' were created in the first place. The side benefit of letting you define your OS libraries, and other things, is a nice bonus, and way overblown in my opinion. Docker and its tooling is just plain bad. It's so bloody unstable, unless you pick some esoteric combination of versions and storage backends (old docker + old aufs + old ubuntu seems to do the trick) - and even then, you'll run into problems. Documentation won't help you here - it's trial and error. The docker group seems focused on feature, feature, feature, while the basic stability and performance remains poor. It's quite amazing how they get it so wrong. Browse through the github issues for performance and hanging issues. The surrounding tooling is poor as well - registry v2 doesn't even support deletes (because they need to maintain compatibility with the 100000 different storage backends for it). There is no LTS release, bug fixes only happen in latest version, so you're in a constant state of brokenness. And so on.
- ChoHag 10y ago
  The concept is great but it's also not original. It's called "processes". Docker is little more than a mass of complication laid atop fork+exec. That's why nobody can get it right - because we already did.
  - IshKebab 10y ago
    I totally agree. The real issue is dynamic libraries and how hard it is to compile C/C++ code statically with GCC. If you could just pass `-static` to gcc and it actually worked like you expect this would never have happened. Fortunately that seems to be changing somewhat. Go is totally static, and Rust can easily be made totally static using muscl. You can even do totally static C/C++ apps fairly easily with muscl.
    - jjnoakes 10y ago
      Dynamic libraries (in the C/C++ sense) only scratch the surface. Containers give you your own file system namespace (among other namespaces), which means all of the files that make up your complicated application unit can be put together and work together in isolation, separate from the machine's main file system.
Philipp__ 10y ago
Docker is just overhyped deal with it. There are some nice ideas, but nothing that we couldn't or haven't seen before. FreeBSD Jails and Solaris Zones exist for more than ten years. Where they addressed many things that Docker didn't.
- vacri 10y ago
  Can you download a BSD Jail image from an application's website, and have it 'just work'?
  - Philipp__ 10y ago
    No, but I do not see how it is related to my comment. Read more carefully. I didn't say that Jails and Zones did everything that Docker did, yeah DockerHub is cool and I gave them credits for that.
    - deleted 10y ago
      [deleted]
    - fyolnish 10y ago
      Federation credits?
    - paulddraper 10y ago
      "nothing that we couldn't or haven't seen before"
      - deleted 10y ago
        [deleted]
  - cookiecaper 10y ago
    Yeah, surface simplicity seems to be the heart of what drives tech fads, even if the actual cost in labor and effort is exponentially larger on the back end. MongoDB? Yes, don't worry about data design or normalization! Just throw that stuff in there, call it anything you want! Finally programmers are free from the tyranny of decent databases. I can't think of any downsides to that arrangement. Docker? Yeah man, you can just say "docker pull redis" and then you don't even have to bother with Ubuntu getting in your grill with all of its apt-get shenanigans. It's awesome! Now how do we make that port accessible...
ownagefool 10y ago
I think the container example is actually more apt than you think. Running out of memory is a bit like running out of space in the container. If I dropship a container on your yard, you're going to have a container but your options in what to do with it are limited. Now if your container has a lifecycle and a scheduler because it needs to be in China on Wednesday, you suddenly have a lot more complexity. Docker itself being a buggy piece of crap is neither here now there in the grand scheme of things.
vidarh 10y ago
They're "complex thingamabobs" because our applications are. Which is exactly why we want to wrap them up and isolate them and expose as narrow interfaces as possible. Containers are a symptom of our still immature ways of building applications. The problems you bring up would still be there without containers, but you might not notice them, until you e.g. want to bring your setup over to another machine, for example. Or want to duplicate it somewhere else. Or want to upgrade something else on you machine that just happens to interact badly with your setup.
pjmlp 10y ago
As others say Docker is probably over-hyped technology. However, I do see it as positive, because its hype, regardless if good or not, has created the traction for Go and OCaml on the data center, thus eventually leading to less C code for such use cases. So hype or not, maybe we do get some security improvements on the overall stack.
- saji13 10y ago
  Out of curiosity, why is less C code a good thing?
  - pm90 10y ago
    Maintenance. A lot of the younger programmers have very little experience with running/working with C code and stack; they are a lot more comfortable with Java/Python/Go (for backend). So the less C code you have to deal with in your stack, the easier it is for deployment/debugging. Not to mention, the more modern languages also provide many features that allow pinpointing errors faster etc.
  - pjmlp 10y ago
    Security exploits caused by memory corruption, undefined behavior, ability to inject code, numeric overflows plus whatever is common to all memory safe languages. https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php
  - sidlls 10y ago
    There are legitimate reasons to not want to use C, but I find around here it's mainly reflexive hate and language zealotry. It's popular to hate on C (and C++) because the languages are so ubiquitous and long-used that a large body of terrible, unsecure, and poorly written code exists using them. Other languages haven't had the same success as these two yet, so haven't had their warts exposed enough to be dumped in the "automatically hated" category. Java comes close, but it also is typically lumped in the "automatically hate it" bucket and for similar reasons.
    - 10y ago
Gruselbauer 10y ago
I'm doing the same with a couple of containers and my experience is pretty much the opposite. What containers are you using, if I may ask? I'm using jwilder's nginx rproxy container, the let's encrypt helper container for that plus half a dozen Web apps on a VPS. Among those Weechat, two instances of vanilla nginx, rutorrent, dovecot, mattermost, nextcloud and a test environment for my Python tinkering. Works like a charm. Upon bringing up a new container, I supply the desired subdomain and my letsencrypt user data, the container comes up and uses SSL plus automatically renewed certificates. My Docker experience so far - in a private, limited, very much not production environment - has been "virtualisation light" all the way. I think of Docker as a somewhat extended chroot, to wrap my mind around it.
dragonsh 10y ago
Containers!=docker, I think if you used lxd container, your experience might have been different as they work like virtual machine. I am using lxd in production and it has been a pleasure with live migration, snapshots and good old configuration management using ansible.
- haalcion3 10y ago
  And, as probably everyone knows, Google runs everything in containers and has been using containers for a decade: http://www.nextplatform.com/2016/03/22/decade-container-control-google/ http://www.nextplatform.com/2016/03/22/decade-container-cont... Docker may be flawed, but containers aren't. If you need some enterprise leader to tell you this instead, here are some Gartner posts showing this is the way: VMs may be well established and "magic quadrant", but they are also on decline, and containers make better use of hardware/resources: http://www.informationweek.com/cloud/infrastructure-as-a-service/virtualization-market-now-mature-gartner-finds/d/d-id/1325529 http://www.informationweek.com/cloud/infrastructure-as-a-ser... It's important what you use to roll out containers and requires forethought: https://www.gartner.com/doc/3267118/containers-change-data-center-infrastructure https://www.gartner.com/doc/3267118/containers-change-data-c...
  - pm90 10y ago
    What really surprises me about Google is why they don't open source some of these great core technologies (MapReduce, Containers etc.) instead of publishing theory as academic papers. On the one hand, it may be a great way of promoting the creating of these tools from the ground up, inspired by the theory alone. On the other hand, Google's invaluable experience with using these technologies probably means their versions are more stable, faster, resilient etc.
    - haalcion3 10y ago
      Kubernetes: http://kubernetes.io/ http://kubernetes.io/ Google Container Engine: https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/ Open-source MapReduce implementation: https://gigaom.com/2015/02/18/google-open-sources-a-mapreduce-framework-for-c/ https://gigaom.com/2015/02/18/google-open-sources-a-mapreduc... https://github.com/google/mr4c https://github.com/google/mr4c
lowbloodsugar 10y ago
Someone told me that I should switch to using shipping containers instead of my current method. Unfortunately, when my cattle arrived in the US, they were all dead. I was told containers "would just work". After some experimentation, we managed to get our cattle in a container by building a system that correctly managed food and waste. Then we found a partner who had successfully packaged sheep and so we just used that. Unfortunately, they appeared to have a leak in their waste management system, and the container overflowed and all the sheep died. We did not have this problem when the sheep were able to fill the entire hold with their output. Clearly the idea that shipping containers just work is a gross oversimplification. In fact containers seem to be complex thingamabobs with multiple points of failure.

by dancek 10y ago

hvidgaard 10y ago

I wanted to write about my experience with containers. It mimics yours. The idea of a container is beautiful and elegant. The execution, not so much. I'm more or less convinced that to reduce this complexity, we need a limited scope ecosystem. Microsofts .Net would probably be a good place to start, but MS, being enterprise, have a habit of turning things into a mess of configuration.

chewchew 10y ago

Docker gives you the building blocks, but that means you have more pieces to arrange and manage. Take a look at Docker Compose if you haven't already, since the Docker CLI only gets you so far when you're creating apps that consist of multiple containers. I think the best approach for your cert issue is to abstract that into a separate service (nginx is an option, but I'd recommend the Rancher approach below). Yes, that means you have to add another container, but that's just another block in your docker-compose.yml file. Embrace the approach of separating your components into containers and organizing them as a stack. You can easily link containers together, share data volumes, and start/stop individual containers or the stack as a whole. The problems that you're having are pretty easy to fix with some tooling. Rancher (http://rancher.com/ http://rancher.com/) greatly simplifies the cert issue by allowing you to import certs and provide them to the Rancher loadbalancer service (which you can add to any stack). There's also a LetsEncrypt community catalog template that automatically retrieves and imports certificates to Rancher. There are other open source orchestrators like DCOS, but Rancher is probably the simplest to use, and it's the only one I'm very familiar with. There are SaaS options that you can look into, but I don't have experience with them. As for the container crashes, it's trivial to automatically restart them. Just pass the --restart=always flag to the Docker run command. You can also add the flag to a docker-compose.yml file.

beachstartup 10y ago
> but that means you have more pieces to arrange and manage wait. aren't these things supposed to give us less pieces to arrange and manage? > The problems that you're having are pretty easy to fix with some tooling yes, of course the solution is more tools. what exactly was the problem again?
- chewchew 10y ago
  > wait. aren't these things supposed to give us less pieces to arrange and manage? No, not fewer pieces. You'll have more pieces, but you can combine the pieces and control them individually or as a group. You can think of Legos, since you have many pieces but they all fit together in the same way. Docker compose lets you group these containers together, and that is what ultimately makes it feel like you have fewer pieces to manage. With that, you can start/stop a stack of containers (e.g. django, nginx, postgres, redis) with a single command, but still inspect and manage each component separately. This is something you might normally do with bash scripts, but with Docker you can take that same app to an orchestration platform and run it on any host. Run it on your laptop, run it on a linux server, run it on a SaaS provider like Docker Cloud, run it on a private cloud with an orchestration platform. > yes, of course the solution is more tools. what exactly was the problem again? Docker is just the foundation. Nothing more. I'm fine with learning more tools because I feel that the foundation is solid. The problem is being able to ship and manage your apps. That is much, much easier for me now and I'm very glad I invested the time.
- pm90 10y ago
  Its somewhat akin to microservices, where you split each functionality into its own service rather than having one monolith do everything.
dancek 10y ago
Thanks, I'll have to look into Rancher. I'm already using Docker-compose. Also good to know about automatic restarts. I don't know how I missed that, I had to read a lot of docs to get where I am. Still, the amount of tooling that exists and the knowledge needed to pick the right ones for a given situation goes to show that this isn't as simple as packing a shipping container and letting someone ship it...

jbverschoor 10y ago

Same here with docker. The ideas are nice as an application, but it's just a pain in the ass. LXC on the other hand is a breeze.

dancek 10y ago
Does LXC provide a way to automatically create new working instances (like a Dockerfile / docker-compose.yml)? I'm not quite grokking LXC in my first 10 minutes of reading...
- gautamdivgi 10y ago
  I think you could create your own lxc template and then create new instances. The other way would be to just clone existing working instances with overlayfs. Base lxc may be a bit of a pain. Look at lxd - I believe that makes things much much simpler. Another thing about lxc is the unpriviledged container - which I think is great for security (not sure if docker provides this).
- contingencies 10y ago
  man lxc.conf ... this is your dockerfile equivalent.
sergiosgc 10y ago
LXC is nice, as a building block, but it is far from "a breeze". It is refreshing, however, being able to write, in a couple of hours, a setup script from scratch that debootstraps an install, chroots in there to configure it and launches the container via systemd-nspawn. Very few moving parts, excellent for development environments. Not yet something I trust in production, though.

nikcub 10y ago

You might have better luck with container specific reverse-proxy like Traefik[0] - it has builtin Let's Encrypt support with auto-renewal > I had a huge amount of headaches to get it actually working. Moving from running one container to running multiple containers is probably one of the most confusing parts of getting started with Docker There are a large array of orchestration options and tools - each with their own pros and cons: Swarm, Kubernetes, Mesos, Marathon, Mesosphere, Centurion, Rancher, etc. Docker 1.12 now having built-in orchestration with Swarm should make this easier[1]. [0] https://github.com/containous/traefik https://github.com/containous/traefik [1] https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/ https://blog.docker.com/2016/06/docker-1-12-built-in-orchest...

dancek 10y ago
Traefik sounds great! I'm using https://github.com/SteveLTN/https-portal https://github.com/SteveLTN/https-portal which is a Docker container, and that kind of setup is just complicated. Putting the reverse proxy outside sounds much cleaner.

nvarsj 10y ago

Docker is a poorly engineered and over-hyped technology. The concept is great - and in fact, many companies have built great tooling around Linux cgroups. It lets you efficiently binpack applications on a single server - which is why 'containers' were created in the first place. The side benefit of letting you define your OS libraries, and other things, is a nice bonus, and way overblown in my opinion. Docker and its tooling is just plain bad. It's so bloody unstable, unless you pick some esoteric combination of versions and storage backends (old docker + old aufs + old ubuntu seems to do the trick) - and even then, you'll run into problems. Documentation won't help you here - it's trial and error. The docker group seems focused on feature, feature, feature, while the basic stability and performance remains poor. It's quite amazing how they get it so wrong. Browse through the github issues for performance and hanging issues. The surrounding tooling is poor as well - registry v2 doesn't even support deletes (because they need to maintain compatibility with the 100000 different storage backends for it). There is no LTS release, bug fixes only happen in latest version, so you're in a constant state of brokenness. And so on.

ChoHag 10y ago
The concept is great but it's also not original. It's called "processes". Docker is little more than a mass of complication laid atop fork+exec. That's why nobody can get it right - because we already did.
- IshKebab 10y ago
  I totally agree. The real issue is dynamic libraries and how hard it is to compile C/C++ code statically with GCC. If you could just pass `-static` to gcc and it actually worked like you expect this would never have happened. Fortunately that seems to be changing somewhat. Go is totally static, and Rust can easily be made totally static using muscl. You can even do totally static C/C++ apps fairly easily with muscl.
  - jjnoakes 10y ago
    Dynamic libraries (in the C/C++ sense) only scratch the surface. Containers give you your own file system namespace (among other namespaces), which means all of the files that make up your complicated application unit can be put together and work together in isolation, separate from the machine's main file system.

Philipp__ 10y ago

Docker is just overhyped deal with it. There are some nice ideas, but nothing that we couldn't or haven't seen before. FreeBSD Jails and Solaris Zones exist for more than ten years. Where they addressed many things that Docker didn't.

vacri 10y ago
Can you download a BSD Jail image from an application's website, and have it 'just work'?
- Philipp__ 10y ago
  No, but I do not see how it is related to my comment. Read more carefully. I didn't say that Jails and Zones did everything that Docker did, yeah DockerHub is cool and I gave them credits for that.
  - deleted 10y ago
    [deleted]
  - fyolnish 10y ago
    Federation credits?
  - paulddraper 10y ago
    "nothing that we couldn't or haven't seen before"
    - deleted 10y ago
      [deleted]
- cookiecaper 10y ago
  Yeah, surface simplicity seems to be the heart of what drives tech fads, even if the actual cost in labor and effort is exponentially larger on the back end. MongoDB? Yes, don't worry about data design or normalization! Just throw that stuff in there, call it anything you want! Finally programmers are free from the tyranny of decent databases. I can't think of any downsides to that arrangement. Docker? Yeah man, you can just say "docker pull redis" and then you don't even have to bother with Ubuntu getting in your grill with all of its apt-get shenanigans. It's awesome! Now how do we make that port accessible...

ownagefool 10y ago

I think the container example is actually more apt than you think. Running out of memory is a bit like running out of space in the container. If I dropship a container on your yard, you're going to have a container but your options in what to do with it are limited. Now if your container has a lifecycle and a scheduler because it needs to be in China on Wednesday, you suddenly have a lot more complexity. Docker itself being a buggy piece of crap is neither here now there in the grand scheme of things.

vidarh 10y ago

They're "complex thingamabobs" because our applications are. Which is exactly why we want to wrap them up and isolate them and expose as narrow interfaces as possible. Containers are a symptom of our still immature ways of building applications. The problems you bring up would still be there without containers, but you might not notice them, until you e.g. want to bring your setup over to another machine, for example. Or want to duplicate it somewhere else. Or want to upgrade something else on you machine that just happens to interact badly with your setup.

pjmlp 10y ago

As others say Docker is probably over-hyped technology. However, I do see it as positive, because its hype, regardless if good or not, has created the traction for Go and OCaml on the data center, thus eventually leading to less C code for such use cases. So hype or not, maybe we do get some security improvements on the overall stack.

saji13 10y ago
Out of curiosity, why is less C code a good thing?
- pm90 10y ago
  Maintenance. A lot of the younger programmers have very little experience with running/working with C code and stack; they are a lot more comfortable with Java/Python/Go (for backend). So the less C code you have to deal with in your stack, the easier it is for deployment/debugging. Not to mention, the more modern languages also provide many features that allow pinpointing errors faster etc.
- pjmlp 10y ago
  Security exploits caused by memory corruption, undefined behavior, ability to inject code, numeric overflows plus whatever is common to all memory safe languages. https://www.cvedetails.com/vulnerabilities-by-types.php https://www.cvedetails.com/vulnerabilities-by-types.php
- sidlls 10y ago
  There are legitimate reasons to not want to use C, but I find around here it's mainly reflexive hate and language zealotry. It's popular to hate on C (and C++) because the languages are so ubiquitous and long-used that a large body of terrible, unsecure, and poorly written code exists using them. Other languages haven't had the same success as these two yet, so haven't had their warts exposed enough to be dumped in the "automatically hated" category. Java comes close, but it also is typically lumped in the "automatically hate it" bucket and for similar reasons.
  - 10y ago

Gruselbauer 10y ago

I'm doing the same with a couple of containers and my experience is pretty much the opposite. What containers are you using, if I may ask? I'm using jwilder's nginx rproxy container, the let's encrypt helper container for that plus half a dozen Web apps on a VPS. Among those Weechat, two instances of vanilla nginx, rutorrent, dovecot, mattermost, nextcloud and a test environment for my Python tinkering. Works like a charm. Upon bringing up a new container, I supply the desired subdomain and my letsencrypt user data, the container comes up and uses SSL plus automatically renewed certificates. My Docker experience so far - in a private, limited, very much not production environment - has been "virtualisation light" all the way. I think of Docker as a somewhat extended chroot, to wrap my mind around it.

dragonsh 10y ago

Containers!=docker, I think if you used lxd container, your experience might have been different as they work like virtual machine. I am using lxd in production and it has been a pleasure with live migration, snapshots and good old configuration management using ansible.

haalcion3 10y ago
And, as probably everyone knows, Google runs everything in containers and has been using containers for a decade: http://www.nextplatform.com/2016/03/22/decade-container-control-google/ http://www.nextplatform.com/2016/03/22/decade-container-cont... Docker may be flawed, but containers aren't. If you need some enterprise leader to tell you this instead, here are some Gartner posts showing this is the way: VMs may be well established and "magic quadrant", but they are also on decline, and containers make better use of hardware/resources: http://www.informationweek.com/cloud/infrastructure-as-a-service/virtualization-market-now-mature-gartner-finds/d/d-id/1325529 http://www.informationweek.com/cloud/infrastructure-as-a-ser... It's important what you use to roll out containers and requires forethought: https://www.gartner.com/doc/3267118/containers-change-data-center-infrastructure https://www.gartner.com/doc/3267118/containers-change-data-c...
- pm90 10y ago
  What really surprises me about Google is why they don't open source some of these great core technologies (MapReduce, Containers etc.) instead of publishing theory as academic papers. On the one hand, it may be a great way of promoting the creating of these tools from the ground up, inspired by the theory alone. On the other hand, Google's invaluable experience with using these technologies probably means their versions are more stable, faster, resilient etc.
  - haalcion3 10y ago
    Kubernetes: http://kubernetes.io/ http://kubernetes.io/ Google Container Engine: https://cloud.google.com/container-engine/ https://cloud.google.com/container-engine/ Open-source MapReduce implementation: https://gigaom.com/2015/02/18/google-open-sources-a-mapreduce-framework-for-c/ https://gigaom.com/2015/02/18/google-open-sources-a-mapreduc... https://github.com/google/mr4c https://github.com/google/mr4c

lowbloodsugar 10y ago

Someone told me that I should switch to using shipping containers instead of my current method. Unfortunately, when my cattle arrived in the US, they were all dead. I was told containers "would just work". After some experimentation, we managed to get our cattle in a container by building a system that correctly managed food and waste. Then we found a partner who had successfully packaged sheep and so we just used that. Unfortunately, they appeared to have a leak in their waste management system, and the container overflowed and all the sheep died. We did not have this problem when the sheep were able to fill the entire hold with their output. Clearly the idea that shipping containers just work is a gross oversimplification. In fact containers seem to be complex thingamabobs with multiple points of failure.