Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 116 posts

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#91

Post by eicnix »

rollulus wrote: post #75
eicnix wrote: post #14

Openshift is essentially Kubernetes + Redhat Extensions + Redhat Support I use Gitlab CI and helm[1] for deploying. The last step of the ci process checks out the helm chart which is just another git repo and executes a helm install/upgrade CHART-NAME. Making things accessible is done through kubernetes ingress with nginx[2](which includes getting let's encrypt automatically for all external endpoints) so when I want…

Hi, nice, this is a lot similar to our initial approach. Glad to see that! To make this flow a bit more easier, we've created a tool [1] (apologies for the plug) that is on top of Helm. What it does, is taking a diff between a bunch of Chart references with values (the desired state) and what's currently in Kubernetes (the actual state), and perform a few create/updates/deletes. So for instance you don't have to add…

Hi rollulus,

thanks for the info. As far as I understand it you configure the state of the helm release + configured values in a file and apply it to a kube cluster. Depending on your cluster setup this is really helpful. Do you have a solution for triggering a rolling update of pods if a configmap has changed? In your examples I didn't see any configmaps.

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#92

Post by thesandlord »

wstrange wrote: post #41
jhspaybar wrote: post #10

I use Convox ( http://www.convox.com ). It is backed by ECS which gets me out of the infrastructure game for the most part and the CLI interactions in Convox are similar to heroku style commands so the learning curve is much simpler than deploying and learning my own Kubernetes or OpenStack or ECS configurations. They've also thought of the other things you need like environment based secrets(uses DynamoDB and KMS be…

If you don't want to manage Kubernetes, you can use Google Container Engine (GKE), which is Kubernetes-as-a-service. A nice bonus is that they only charge you for the minion nodes. The Kube master is free.

The master is free for small clusters (0-5 nodes). After that, you pay for it.

https://cloud.google.com/container-engine/pricing

(I work for Google Cloud)

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#93

Post by ibotty »

blktiger wrote: post #33
zalmoxes wrote: post #3

I recently(past 6 months) joined a new startup as the operations person, and we standardized on kubernetes for deployment. In the past I've worked with puppet/chef/ansible/heroku/aws/appengine/vmware you name it, and Kubernetes is the nicest and most flexible platform to build on top. There's a learning curve, and new features are being added, but at this point I would not hesitate to recommend Kubernetes to just abo…

If you are doing a lot with docker images, it might be worth considering Concourse CI ( https://concourse.ci ). I haven't played with it in any depth yet so I'm not sure how it compares with other solutions, but I like the idea of your entire build pipeline running through docker images. Theoretically you should even be able to run it in kubernetes.

unfortunately concourse when not deployed with bosh does not have any automation (spawning workers, auto-discovery).

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#94

Post by spudfkc »

At my last job, we started off using Mesos and Marathon, but eventually ended up dropping that in favor of a homemade solution using SaltStack (the manager demanded we drop Mesos/Marathon and use Salt - it was pretty shitty).

At my current place, we are using Teamcity to run tests and build images, and Rancher for the orchestration part. I built a simple tool to handle auto-deployments to our different environments.

I cannot recommend Rancher enough. Especially for small teams, it's just a breeze to set up and use.

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#95

Post by spudfkc »

rickr wrote: post #9

I've been working on creating a platform for a non profit to get veterans coding ( http://operationcode.org/ ). We're a slack based community and have been rolling out some home grown slack bots and we currently have a rails app hosted on heroku. Managing and keeping track of the different apps was getting unwieldy so in an effort to consolidate our apps and reduce costs I evaluated a few different options. I ended u…

I do something very similar but with GitHub and Teamcity.

Automating the upgrades (i.e. redeploys) in Rancher is pretty straight forward - their API is super easy to use. I ended up writing a simple tool in mostly Bash to handle it, and threw it in a Docker container to run on Teamcity.

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#96

Post by peu4000 »

I work at an established company and most of our apps are still deployed with RPM and puppet.

For our dockerized services we use Nomad internally and for a different product we've built in AWS we're using Elastic Beanstalk with all of the resources defined in terraform.

We use jenkins to manage the CI/CD for each method.

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#98

Post by errordeveloper »

At Weaveworks, we have a built a tool called Flux [1]. It is able to relate manifests in a git repo to images in container registry. It has a CLI client (for use in CI scripts or from developer's workstation), it also has an API server and an in-cluster component, as well as GUI (part of Weave Cloud [2]).

Flux is OSS [3], and we use it to deploy our commercial product, Weave Cloud, itself which runs on Kubernetes.

1: https://www.weave.works/continuous-delivery-weave-flux

2: https://cloud.weave.works

3: https://github.com/weaveworks/flux

Re: Ask HN: Docker, Kubernetes, Openshift, etc – how do you deploy your products?

#100

Post by hosh »

hiphipjorge wrote: post #48
hosh wrote: post #23

I'm working for a startup right now. We're using Kubernetes via GKE on Google Cloud. Back in 2015, I implemented a Kubernetes by hand in AWS. I'm not going to do something like that again. GKE is fairly painless and it has most of the sensible defaults that I want. Networking just works -- pods can talk to each other as well as to any VM instances from any availability zone and region. Integrating with GCP service ac…

> . I have deployed with AWS ECS service (not doing that again; it does not have the concept of pods which severely constrains how you deploy) What have you found are the biggest advantages of pods over containers? How does ECS constrain how you deploy? Are you simply referring to rollout/rollback, scale up/down?

The last time I used ECS for a production deploy, you could group containers together (just as you can on compose). However, there were no easy way to do service discovery. This made wiring containers together difficult. If I wanted one container to talk to another, I had to group them and deploy them as one unit.

That meant I could not horizontally scale one container more than the other. I can scale the whole group, but there is a lot of wasted resources at that point.

Kubernetes pods group containers together under a single IP address. Containers from one pod (one IP address) can talk to any other pod. Docker did not even have this functionality until 1.12, and that is too little, too late. (And I am not sure this is something ECS supports right now). Combined with label selectors, long-running services (which binds a DNS name to the set selected by the label selectors), I can horizontally-scale pods and still maintain service discoverability. Using DNS makes service discovery stupid-easy. This means I can scale Kubernetes pods independently from each other.

Another consequence of using Service objects to select a set based on label selectors is routing can now be dynamic. Pods that need to talk to another pod goes through the service. I can then scale the dependency up and down, and it doesn't really affect the pod that requires that service. I can do rolling upgrades to the dependency, and it works because Service abstracts that through label selectors.

There are still some warts related to this setup. Stateful sets still needs a lot of work. I've also found that many applications caches IP addresses (redis sentinel being a notorious example). To work well with Kubernetes, it's better to always query DNS when making a connection. Ruby drivers for Mongodb and Redis, for example, will cache DNS lookup, making failover fragile (if you are running Mongodb and Redis inside Kubernetes; if you're not, you won't have this problem).

I was choosing between Kubernetes and Mesos after ECS, but had not looked into either deeply. It was random chance that took me to Kubernetes instead of Mesos. Kubernetes solved many of the pain points of Docker Compose and ECS.

Post reply on HN