31–40 of 134 posts
I would like to see more vetting in dockerhub and security in general, yes it's based on cgroups which are specifically security minded, but not all docker users are aware of this. A novice user pulling a random docker image, and running default as root is bound to cause some issues.
Earlier quoted context omitted.
I had this problem too when my team first adopted docker, but you can use a conventional debugger if you run your container interactively (with -i.)
Yea, first you just have to get your debugger (and maybe the rest of your toolchain) installed in the container, along with your source code.. and then you run into things like crazy wonky terminal support. Sucks if you want to use a more advanced debugger interface, because you're not going to install that in the container.
In your `debug` build, include a debugger. Use this to debug. In your `release` build, just include the app and its dependencies. Use this in prod.
Oh geez, having a team of 24 engineers across multiple countries trying to maintain a common set of bash scripts that work for 12+ unique services sounds like a disaster. Instead we have a single workflow for docker, whether it's going out to AWS or Kubernetes and all the services use an identical flow. Integration testing is a cinch since it's running actual, version matched postgres/redis/etc on the CI nodes which…
And that's just the "legitimate" stuff. The amount of hours that we've wasted on things like "X runs docker 1.9 but Y runs docker 1.10", or overlay bugs, or image pruning failures, is insane. Breaking things is an inevitable side effect of progress but maybe infrastructure software shouldn't break this much...
Far from me to say that 20+ engineers across the world maintaining bash scripts for a dozen services is better. I used to do that and it was extremely terrible. Even when everyone involved had years of experience and the mundane task of updating deployment scripts wasn't delegated to interns, the way it is today (for reasons that I am entirely unable to comprehend). Definitely far more terrible than Docker. Docker is not as terrible, but still pretty terrible.
I'm open to the possibility that I've been doing it wrong, and that every team I've worked in/every customer I've worked for has been doing it wrong. But this has been going on for like four years now and enlightenment doesn't seem to be any closer to hitting me...
The author's approach presupposes a devops "person" (side note: if you have a person in charge of ops, that person is an ops person, not a "devops" person, as devops is a process; either your org is on it or they aren't). If you want developers to launch to production with any degree of reliability, you're going to need either a lot of tooling support for your specific workflow, or you're going to use docker and a si…
I completely agree. My team has spent the last several years building software we then deploy with Docker and Kubernetes, and looking back I think that our software would have been much better deployed as statically-linked binaries on simple Linux servers. We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker bu…
The archive link is down and the original article is dead, so I can't read it... The comments on the article are not kind, however [1][2]. 1. https://www.reddit.com/r/devops/comments/8j9yrn/docker_is_th... 2. https://www.reddit.com/r/docker/comments/8jk22u/docker_is_a_...
Earlier quoted context omitted.
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing func…
Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.
Earlier quoted context omitted.
It's a bit more than that; there's a reason the next job cares that Docker, React, or Kubernetes are on your résumé. If you use Docker, you get to claim that you're familiar with a framework atop a lower-level abstraction, and the lower-level abstraction is flexible to the point of incomprehensibility; few people enjoy maintaining someone else's bespoke shell script environment, and there's not much of a forcing func…
Do you actually think Kubernetes infrastructure is built without hair-pulling and rage? If so, I've got some stories for you.
I completely agree. My team has spent the last several years building software we then deploy with Docker and Kubernetes, and looking back I think that our software would have been much better deployed as statically-linked binaries on simple Linux servers. We're writing in Go, which means we already have the statically-linked binaries, which means we have a single file which needs to get deployed. What does Docker bu…
Amazon (and other FAANGs) use OS packages and do not use Docker nor Kubernetes or anything with all that complexity. This is a deliberate choice, at least in Amazon.