> Where to put logs
Well, I just throw them aside and use `docker logs [container]`
> How to manage state
One container should perform one service. I haven't run into a problem here.
> How to schedule containers
ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running.
> How to inspect app
`docker exec -it [ container id ] bash` ("ssh" into container)
`docker -f logs` (follow logs)
> How to measure performance
Probably same way you measure system performance
> How to manage security
Everything of mine is in a VPN; some services can talk to certain services over certain ports... Personally, I don't really understand all this talk about security. Protect your systems and that should protect your containers. Why is it that isolated processes are causing people to throw up their arms like security is an unimaginable in such a world? There are ways..
> Consistency across docker containers
This can be a pain if you need this, yea. They see to be adding better & better support to allow containers to talk to one another (and ONLY to one another).
> Ain't nobody got time for that.
Hmm, personally I don't have time to go thru what Puppet, Chef, and even Ansible require to get your systems coordinated. I see this as far more work than creating a system specification within a file and finding a way to run it on some system.
All comes down to requirements though and where your technical stack currently is at. To any newcomers who are also plowing into the uncertain fields of a dockerized stack, fear not! You are in good company and if I can make it work, you can too.
1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER.
2) What if your container dies? What if your host dies? Do you have any state at all or have you abstracted that out? Are your systems distributed
3) Always running does not answer finding where to run them
4) That only works if the container is running. What if it died? Also, docker logs is a fool's game
5) bingo, that's right at least
2 - If a system dies and it has a state, then what do you do? If a dockerized process dies, and it has a state, then what do you do? This isn't some new problem to Docker. If my database service dies, you know what happens? It starts back up and connects to the persistent volume. Personally speaking, yes all of my services / systems are distributed.
3 - Most people don't need to start their services exactly at this point and then stop at another certain point (which is why I pretty much brushed over it). If they do, there's plenty of tools to do this that can also utilize docker.
4 - What if a system died? Does this mean you SSH'ing in isn't a viable option? (yes...)
5 - Yes, you love negativity so clearly this is your favorite
6 - ...? What? Do you have something more to say?
It's cute that you like to poke holes and personally attack people, but really my comment was just how I go about things on a day-to-day basis. This is coming from someone who has 6 major Docker services abstracted out running all the time across 3 environments.. all capable of being updated via a `git push`. I think I have decent, practical advice to offer for other docker-minded practitioners and just decent advice to newcomers.
Your grievances circle around logs not being centralized, easily-accessible (1, 2, 4).. You also don't outline any solutions yourself.
Yes, the unrotated container logs are kept in a root-accessible-only location in a directory named after a long key that changes on every image restart - not conducive to manual log inspection, and definitely not conducive to centralised logging. That's not a 'system problem', it's Docker just being rude. Yes, a relatively experienced engineer can work around that... but why should they need to 'work around' it in the first place?
Ironic really, that if you put a user in the 'docker' group, that they can do anything they want with the docker process, destroying as much data as they like or spinning up containers like nobody's business... but they can't see the container logfiles.
Even without that issue, I'd prefer my logs to be centralised. So as well as my app should I be running a logging daemon, process monitoring, etc for each docker instance?
People are not kidding through, when they say that everything gets very complicated. All the things that we did by convention and manual configuration in regular VMs that are babysat manually have to be codified and automated.
Docker is going to be a great ecosystem in 3 years, when the entire ecosystem matures. Today, it's the wild west, and you should only venture forth if having a big team of programmers and system administrators dedicated just to work on automation doesn't seem like a big deal.
Stop with the blaming statements.
This avoids saying "You're an idiot", which is nearly never constructive or helpful, and instead makes education and cooperation its goal. Most people respond better to that.
Who the fuck cares? Why are you debating if you should call someone an idiot or not? My personal philosophy is to be nice to others, always because I don't know what they're going through. What's there to be gained by not only calling someone an idiot but defending it on the meta scale? Yes we should always cloak our rebuttals with negativity -- for what other way could there be?! I must call this person an idiot, don't you see?! 50% of people are below average intelligence -- surely I must let them be aware of the fact that I believe they're mundane and forgettable!
I don't care if other people think poorly of me, I'm going to believe in myself... you critics are so annoying. I can't even write a comment trying to help people without jackasses flying in poking holes in what I said AS IF it were gospel! It's a comment! I wrote it in 2 seconds and, sure, maybe I should have put some more time into it but I was just trying to help out anyone who got scared by that list. It's such a different mindset. I didn't set out to be RIGHT, which is what's most holy & sacred around these parts. The best thing that could have happened is some people would have been like, yea but how is X going to solve Y when Z happens? And I woulda been like, good question mate, blah blah and we woulda all been better off.
Instead, a kid comes flying in drunk on keyboard ego and is like "You should stop talking"; think about MY intention vs HIS intention. Think about the INTENTION behind calling someone an idiot and what it does to that person. So stupid.. honestly. There's a bigger picture at play than being right or wrong... You don't do certain things not because it's empirically correct to do it, but because it's the moral thing to do or the mature thing to do or the compassionate thing to do.
If you want to argue "this is the right way", be prepared to bring data and defend your statements.
People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.
Not sure what you're implying either, but you can tell in my comment, I never came out of the gates saying "This is the best way!"
That's why you should talk to the points and not make personal statements like "you shouldn't give advice".
You have to remember that you containers and coming and going all the time, which is one of the biggest challenges. It basically means you have to have everything centralised and that means a lot of additional infrastructure/complexity.
At the end of the day, you have to view it as building a reliable system that performs a function. Docker is one tool you can use to do that. Virtual machines are another tool. They don't solve all the problems you describe, nor are they intended to. If you're a tiny startup, you can just go the AWS route, but that leaves you beholden to AWS and their pricing. That's fine early on, but eventually you'll want to go full-stack for one reason or another.
Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and easy with `sudo apt-get install fail2ban`. Now try to secure CoreOS against sshd attacks. There are guys out there who tried to run fail2ban in a container (without luck) and so far I've only found one hacky script which tries to do the same oO https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blo...
That's not to say you're wrong; containers probably aren't that useful to most small shops. But that summary doesn't make any sense for this article.
Also, see https://titanous.com/posts/docker-insecurity