Live data from Hacker News

WTF is a container?

techcrunch.com

41–50 of 262 posts

Re: WTF is a container?

#41
post #5

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…

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.

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...

Re: WTF is a container?

#42
post #5

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…

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, t…

Hey chewchew you seem to be knowledgeable on docker-compose.

What's the easiest way to get a .yml on a cloud server somewhere and let it assemble it assemble the containers for you?

Also, do you know where containers set environment variables? The official Postgres makes available something like PG_PORT_3542 and u can just refer to it from another container. Where I can't seem to do the same with the Redis one...

Re: WTF is a container?

#43
post #36
post #5

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…

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 ow…

Traefik sounds great! I'm using 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.

Re: WTF is a container?

#44
I guess I'll never get it. Don't most OSs already run processes isolated from each other, have advanced process scheduling mechanisms and manage access to hardware resources? Also with static linking nothing stops you from creating huge binaries that "will run anywhere".

Re: WTF is a container?

#45
post #5

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…

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.

Re: WTF is a container?

#46

Earlier quoted context omitted.

It's up to you to make your containers bloated or keep them slim. You can use the alpine versions of the official Dockerhub images. Python on Alpine is 30 MB (vs 267 MB for the debian one). https://hub.docker.com/r/library/python/tags/ You can create containers that are just a few MB with compiled languages like Go (5 MB). https://www.iron.io/microcontainers-tiny-portable-containers... From the article: "Rather than…

If your app is a compiled go binary (so, it runs anywhere) why do you need a container? The whole point of containerisation is to group installed dependencies (as opposed to installable dependencies like with a regular deb or rpm package) and configuration into a 'black box'. If your binary is already a single-file distribution, why lump it in with the crapfest that is docker?

I don't think that's the whole point. If all you care about is packaging your code in a container, then you don't need Docker. That was solved long ago. Docker simply adds a nice API on top which allows you to package, ship, and manage your apps in the same exact way.

By using something like Docker Compose, you can explicitly define each container and the relationships between the containers. Then, you can start/stop groups of containers (an application stack) while still retaining some component isolation and the ability to upgrade and scale containers independently. All of this is defined in a relatively simple YAML file, which can be committed to VCS and tweaked. I can't tell you how awesome it is to find repos on Github that have use docker-compose. Even complex apps with many pieces can often be launched with a single command. It's easy to take these stacks and tweak them to your needs, adding/removing/changing components as necessary.

Since Docker provides a standard way for managing any container, orchestrators like Swarm, Rancher (my preference for small-medium clusters), and DC/OS can take that functionality and scale it across many hosts. You can get a birds-eye view of your Docker cluster (all apps) or drill down into individual apps and their components. Each container is a uniform piece and can be controlled, scaled, updated, audited in the same way. Throw a UI in front of it and now you can manage applications that you know nothing about. That's great for developers that manage just a few apps, and it's incredible for enterprises with thousands of them. If you don't want to think about infrastructure at all, then you can use a SaaS Docker provider. Obviously there are pros and cons to each approach, and there are some remaining challenges.

Docker isn't perfect, especially in regards to storage and networking. Distributed storage isn't simple, but a lot of progress has been made with volumes and volume drivers. It's not as easy as it needs to be, but the general direction seems to be good and with the proper tooling I think this will be less of an issue.

Re: WTF is a container?

#47
post #44

I guess I'll never get it. Don't most OSs already run processes isolated from each other, have advanced process scheduling mechanisms and manage access to hardware resources? Also with static linking nothing stops you from creating huge binaries that "will run anywhere".

Not with a private root filesystem, a private loopback network, additional security isolation, no requirement for static linking, no.

Re: WTF is a container?

#48
post #21

for the love of god - forget docker, use lxc containers - its simple, secure, goes with its own init, cron, and you dont need to do somersaults to achieve simple tasks. Included with linux kernel. Your own isolated linux system. We use lxc in production for over three years, and we have over 3000 of them. No issues whatsoever.

Doesn't Docker use lxc underneath? [1] [1] http://unix.stackexchange.com/a/254977/152994

Not for a few years now.

Re: WTF is a container?

#49
post #5

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…

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.

Re: WTF is a container?

#50
post #44

I guess I'll never get it. Don't most OSs already run processes isolated from each other, have advanced process scheduling mechanisms and manage access to hardware resources? Also with static linking nothing stops you from creating huge binaries that "will run anywhere".

In containers a few more things are virtualized. The file system is semi-virtualized. Network ports are too. So from the pov of stuff inside the container nothing else is running. That's not true of processes in general. From outside the containers you can then choose how to map parts of the virtual file systems to parts of the real file system and what real network ports the virtual ports connect to etc...

There's more to it. Containers aren't one process theyre as many processes as are launched in that container

Post reply on HN