31–40 of 290 posts
I keep hearing about people putting Docker in dev and test environments and not production. This use case makes no sense to me as you would throw away the entire point of containers and have a wildly inconsistent path to production.
Earlier quoted context omitted.
Because "running things just fine" across production, continuous integration and on dev machines is actually quite a hard thing to do. But then, if you don't feel like you need it, that's probably because you don't need it. (If people are downvoting your question, it's probably because you're giving off a bit of a "I don't understand Docker so it must be crap" vibe, which is not helpful.)
OK, now we're getting somewhere. What is difficult about getting things right across production and CI? What are the pain points? What are the exact problems we're being asked to solve here? I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems. Sorry if my initial question came across with a weird vibe. I'm…
Docker isn't magical, but the process that it lends itself to can be very useful. Those companies aren't using docker to be successful. They are successful because of the processes (and intensity) that docker fits into.
I'm sorry that your colleagues are being asked to drop everything and look at anything (much less Docker). That's not a nice way to work -- and I'm sure it influences their notions of Docker.
I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…
- 1 simple Rest API server, let's say in flask
Dokku - https://github.com/progrium/dokku
Can't really beat `git push deploy/uat`
- 1 database, let's say PostgreSQL
I just run PostgreSQL on the host and connect to it from the containers. Sure I could containerise PostgreSQL itself but I don't really see the point.
I then run my own Dokku plugin (dokku-graduate: https://github.com/glassechidna/dokku-graduate) for graduating my apps from UAT to production.
Some of the points mentioned in the article are in my top hitlist (for decidedly smaller production infrastructure than Shopify): Image building, Logging, Secrets, and Filesystems. But really, the most painful aspect of using Docker in production, at least in environments where you need multiple physical servers (or VMs) is overall orchestration of the containers, and networking between them. Things are much better t…
On these points, what are you comparing Docker to? Using bridged networking, you have pretty much the exact same situation with Docker as without. And just because you're running processes with Docker doesn't mean you have to keep up with dozens of tools for automatic clustering and whatnot. If you want to just start your processes manually, or with Ansible or Makefiles or whatever, you can do that.
I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…
- 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask Dokku - https://github.com/progrium/dokku Can't really beat `git push deploy/uat` - 1 database, let's say PostgreSQL I just run PostgreSQL on the host and connect to it from the containers. Sure I could containerise PostgreSQL itself but I don't really see the point. I then run my own Dokku plugin (dokku-graduate: https://github.com/g…
TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.
I'm confused by this paragraph > Every major deployment of Docker ends up writing a garbage collector to remove old images from hosts. Various heuristics are used, such as removing images older than x days, and enforcing at most y images present on the host. ... More specifically, I'm confused by this sentence, from the above paragraph in TFA: > Most people discover their need by accident when their production boxes…
Hmmm ... tell that to AirBnb (http://nerds.airbnb.com/future-app-deployment/), New Relic (https://blog.newrelic.com/2014/08/12/docker-centurion/ ) and Spotify (https://blog.docker.com/2014/06/dockercon-video-docket-at-sp...)
It is a young technology, but moving quickly. Just 10 years ago, YouTube wasn't owned by Google yet and we didn't have the first iPhone.
Hell, 17 years ago VMware (arguably the king in the virtual machine software market) was founded. If it was a kid, it wouldn't have graduated from high school yet!
Containers are only going to grow in uptake; companies like Weave and ClusterHQ have a very bright future if they can solve real pain points like the ones in this article.
While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…
Even if you're building brand new infrastructure from scratch right now many issues (discussed elsewhere in these comments and the article) are still unsolved.
Earlier quoted context omitted.
- 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask Dokku - https://github.com/progrium/dokku Can't really beat `git push deploy/uat` - 1 database, let's say PostgreSQL I just run PostgreSQL on the host and connect to it from the containers. Sure I could containerise PostgreSQL itself but I don't really see the point. I then run my own Dokku plugin (dokku-graduate: https://github.com/g…
This is exactly the problem here, just run Postgres on the host means that you have a hybrid setup, some of your services dockerized the rest are not. This is not appealing to some people. There are other services mostly in the heavy disk IO space that is not easy to move to Docker. It might be worth to call these out in the documents and save some time to sysadmins figuring this out the hard way. If you want to dock…
I'm running Docker (specifically Dokku) because it drastically simplifies deploying new builds, and graduating those builds between environments.
I know a large part of this article was that Docker complicates rather than simplifies the situation. I guess if you're trying to be a Docker purist (for no reason) then sure. The same is generally true if you try be a purist of any kind.