Between this, Kubernetes, Marathon, Amazon's container service, the tooling is overwhelming. I really have no clue how it all fits together and what a complete setup looks like (dev -> testing/CI -> prod). I'm using Docker for development, but that's where it ends for me.
I've written a report about it for a class last month and it may help you have a better understanding of Swarm/Kubernetes/Marathon: http://armand.gr/static/files/htise.pdf
Not sure if this is helpful, but Firefox uses the pdf.js extension to open pdfs within the browser. Perhaps other browsers have extensions based on pdf.js?
Just a little bit of meta discussion: HN is generally good about this, but at the time I'm writing this, this comment is greyed out. It's a reasonable question that I might have asked 5 years ago. They're not bringing down the level of discourse, they just didn't know something that is common knowledge. I feel like software people, if anyone, should be sympathetic towards people with holes in their knowledge, because we are confronted daily with how large the gulf is between our intellects and memories, and the extant complexity of the world we live in.
PDF's have been known to have exploits and IIRC how mobile treats downloaded pages (HTML) in a web sandbox, IIRC PDF's need to be downloaded to the device to view. Resulting it being a larger security risk than a web page:
I somehow stumbled onto Kubernetes, it met all of my needs for a complete setup, and now I'm sticking to it. I really enjoy using it.
Before that happened, I felt the exact same way. I still do. Docker, HashiCorp, CoreOS, Google and Amazon are all fighting for control, some building on the work of others, some developing their own solutions, some targeting different markets, some targeting the same market. It's incredibly messy, confusing and yet also somehow supposed to make my life easier.
It's the cloud equivalent of the PC world in the 80s: Commodore (64 and Amiga), Apple, TRS-80, IBM, TI, and dozens of smaller players all competing for platform dominance.
Kubernetes is an open source project sponsored by Google. Google offers hosted Kubernetes for the cost of the servers and calls it Google Container Engine. It makes their Cloud Platform more attractive. Ideally, the dependence on Google goes down over time.
>Ideally, the dependence on Google goes down over time.
I know that you're referring to development but just wanted to point out to anyone that might think you're referring to their cloud service that you're not.
Kubernetes is pay for hosting in the case of Google Container Engine, and pay for hosting + support in case of RedHat OpenShift Origin (which leverages Kubernetes). Docker Datacenter appears to be pay for support based off their pricing page at https://www.docker.com/pricing (which just says call for quote basically).
Those are too low level for most users and you'll eventually end up (poorly) re-inventing a PaaS if you need things like configuration, authorisation, scaling, routing, rollbacks, etc. I've found Deis (https://github.com/deis/deis) to hit the sweet spot between flexibility and convenience.
It is built on top of docker and Kubernetes (CoreOS/fleet in v1), and lets you deploy docker containers natively and/or automatically builds those for you using Heroku buildpacks or Dockerfiles when doing git push deployments. You can also drop down to the Kubernetes level if you need to for things that don't really fit the 12-factor app model without breaking Deis.
Convox is another open source PaaS, but we're building it entirely on top of AWS services like CloudFormation, ECS, ASG, etc.
This means it's only suitable for teams that have 100% bought into AWS. If that's you, we make all the hard parts of operating a distributed deployment system Amazon's problem.
I think Empire or Convox will be the right tool for us.
Flynn and Deis etc all seem to be writing their own schedulers and routing layer, where Convox and Empire just reuse AWS components. This to me is a huge plus, since those problems are already solved and rock solid.
But as a developer, I just want to push a docker image some where and scale it up later.
Deis looks amazing! In my current project, I'm running stateful/backing services like Redis, PostgreSQL outside containers. Is that the way to go with Deis as well?
Anything involving state doesn't belong in a container. Personally, I don't think containers are worth investing the mental overhead until the security story is resolved - but if you insist on using them don't use them to store your data.
There's absolutely nothing special about containers and state. A container is just a namespaced process tree. What resources (CPU, memory, network, disk) is has access to is up to you; there's nothing in the Docker design that means state needs to die just because the process dies. All the major container technologies (Kubernetes, Marathon, Amazon's ECS etc.) support data persistence via mounted volumes.
Docker's security concerns are mostly about multitenant systems where you're hosting other people's containers. If all your own apps are your own, then Docker is certainly a step up, securitywise, from running an app as a process running as its own Unix user. You just shouldn't assume that a container is perfectly isolated.
I'm not talking about isolation WRT to containers and security, keeping them up-to-date is the bigger issue. Docker doesn't have a good solution to this that doesn't involve constantly rebuilding your base containers and any child containers that depend on it.
That's not a "security story" I've heard before. Surely containers make this much _easier_ than traditional VMs, because containers are designed (or should be designed) to completely expendable. To do an "OS upgrade", just rebuild and redeploy.
If you're using a system that has rolling, verified, graceful restarts built in (e.g., Marathon, and I believe Kubernetes does, too), you'll easily avoid any downtime, which is harder to accomplish with classical VMs.
With a classical system (VM or otherwise) you'll still have to restart your apps whenever some library (glibc, ImageMagick or whatever) is patched. Docker doesn't change that. It does potentially minimize the surface area.
Major problem is there is a substantial lack of tooling to handle this. Meanwhile, managing updates for all of my servers is pretty painless with the plethora of system management tools out there - puppet keeps all my packages updated from my local yum repositories and restarts services as needed (aside from critical ones like postgresql that require manual intervention).
One possible way to go about this is to use your configuration management tool to update your images. Ansible 2.0 offers a Docker connector which you can use to run a playbook on a container the same way you'd run it on a host.
The playbook tasks would look like:
* Start a new container from the image you want to update
* Using the Docker connector, run your various roles
* Commit the container to a new image
Then you'd push to your registry and redeploy your containers from the updated image.
I suppose there should be something similar for Puppet...
There's also a lot of thrash in this space right now. If you don't have the time or don't want to be a trail blazer use Boring Technology ™ until someone else figures it out for you. Perfectly acceptable approach, imo.
Competition is great until you find yourself standing in the middle of a bazaar with no clue what the fuck is going on, how you got there, or where you're going to go next.
This "Universal Control Plane" thing looks pretty enterprisy. I have to imagine they are ramping up an enterprise sales team now, with all the org changes that come along with that. This product sort of reminds me of Citrix and Xenserver.
I signed up for UCP and was contacted by a few guys at Docker to go over the features. It was an hour-long presentation. They wanted something like ~$1,500 per node. I'm still not exactly sure what a `node` entails. The salesman seemed extremely technical and was able to answer all of the questions I asked. Too bad their website isn't able to give me the directions for using UCP without me clicking on the "sign-up" button (which now doesn't work because I've already signed up), or else we might be using it to deploy at Adobe.
Hi, I'm the founder of Docker. Sorry that you had an issue on the website. I warned the team of your comment, feel free to email me directly at s@docker.com and I'll put you in touch.
Note that the price you mention is yearly. A node is anything you can install Docker Engine on. Typically it's a physical or virtual server. All nodes are combined into a swarm, which you can manage from the control plane.
they are in a position of luxury, for sure. if a serious contender starts cutting into Docker Corp's pie, they'll have to ramp up the other departments.
I hope you didn't take offense to the question. I recognize Docker's contribution to the containerization landscape, but after doing tech for ~15 years, you see things come and go and you get tired of wasting your time on products or tooling that may or may not be around in 1-3 years.
Given the Docker engine has been around for a number of years and it's still picking up steam, containers aren't going away anytime soon. That said, Docker Inc. has plenty of cash in the bank.
Docker Cloud (formerly Tutum) probably only duplicates the control plane aspect of DDC. It's also "in the cloud" versus hosted inside of your own enviroment - which a lot of people with big builds want.
It's not a service as I would think of it. You download and install it on-premise as far as I understand.
I know they call it "CaaS", but I guess they are comparing it to using other PaaS's that can be installed on-premise, such as Cloud Foundry. Personally I find the term confusing, as I'm not sure who the consumer of the service is meant to be (developers creating containers? ops who get a platform for running them?)
In my opinion it require lot of learnings to put Docker Data Center into production and it is still in the early stage. It is a good alternative for companies following everything DIY approach even for creating, deploying and managing containers. But for enterprises who really care about applications and looking for simple, steady and mature option for container based platform cloud foundry is a good alternative. It is more structured and matured platform compared to Docker+Kubernetes as well as Docker+Docker Data Center+UCP combination.
