Welcome to the inaugural episode of the All Things Devops Podcast. This is a brand new podcast from the BigBinary Team where we will discuss all things related to devops.Today we have Rahul and Vishal with us and we will be discussing Rancher, Kubernetes and a couple of the programs and methods that we have been using at BigBinary.Rahul currently handles all the big infrastructure at BigBinary, where over the past six months they have been shipping containers to production, using Kubernetes.Like Rahul, Vishal also works at BigBinary and is currently assisting in developing an internet tool to deploy apps on Kubernetes with a single click.Today we discuss everything from the process and challenges of integrating with Kubernetes, image building, segregating and labelling apps and the latest app building programs. Take a listen!Key Points From This Episode: The setting up process to deploy apps on Kubernetes. Implementing with Rancher versus Kubernetes. Why choose Kubernetes? Alternatives to Kubernetes. Integrating existing development cycles with Kubernetes. Image building with Docker Cloud and Docker Hub. Base images and community image building. Cluster, AWS and Kops communication. Segregating apps on servers. The challenges faced setting up the infrastructure for Kubernetes. And much more!Links Mentioned in This Episode: BigBinary Website BigBinary on Twitter Vipul on Twitter Vishal on Twitter Rahul on Twitter Kubernetes Rancher Docker Cloud Docker Con Google Cloud Shell Kubeadm React NativeTranscriptPlease note the in the discussion Rahul mistakenly said “Katkoda” instead of “Stratoscale”.[[[[[[[This was the traditional setup but when it come to resource management and other things, it was a bit of cumbersome and we are in search of something like related to, which can save on resources as well as the architectural way microservices run.We came across containers, we tried out luckily first using Docker and that turned out to be really useful, but after trying those containers, we were like — we were not supposed to make a call on which orchestration tool to use it. After that, we explored some techniques like Docker data center, Docker swarm and Elastic container service from Amazon.Some of them worked for us but some of them were having this feature but not having the other one and then tried Technologies like Rancher and Kubernetes. Rancher was good, we started off with it, but due to our scale and the features we wanted, we were not able to go complete with Rancher. Then we tried out Kubernetes and it seemed like there was something which was fitting our needs, which was giving scalability and the resource management things what we were looking for.We started exploring Kubernetes from Kubernetes 1.2 and then only we started containerizing our app. So first thing we started was like segregating services in terms of micro services architecture. This is how we started to and decided to use Kubernetes and started containerizing the app.[The environment that we need is something for us, we were using images that have been provided by say CircleCI or we could just start using those images, we could just try to use those machine, provide them to Rancher and get started with it. I know that’s pretty straightforward setting those things up so that I, like myself not being a DevOps, so how exactly the containerization takes place and all of the orchestration for setting those things up was pretty straightforward that I did not need to do those things all by myself.[With all that and implementing it with Rancher, we faced some challenges while using service discovery and with the Kubernetes, it just worked because Kubernetes offers some of the features which really fits into our needs. I would say like Rancher was a great fit but just for our other project, it was not and Native Kubernetes had all the features we were looking for. We started containerizing and automating the steps and that went well.[[[[The only challenge we faced initially was like, we were not going to have the cool UI that Rancher offers.[[[That was one thing when we started off but now with the latest version, 1.7 and keeping an eye on future release of 1.8. That is what’s happening in Kubernetes, to stabilize the Kubernetes driver support. Yeah, I would say, if it comes to being Kubernetes, we have to handle two things. First is like maintaining Kubernetes cluster and for developers, it should be only like deploying apps on Kubernetes and this is where we need to segregate and dashboard or UI specific to developers.This led us to think of like something internal tool, which — internal automation tool, which can hand over to developers to just be specific to deploy apps on Kubernetes.[[Docker bought a project called tumtum or what we pronounce it is at tum-tum, that had a UI for Docker and Docker data center started off, it was in beta but we found that we were something going into vendor locking thing if we were using Docker data center, we were tightly coupled to Docker and this is where technologies like Mesos or Kubernetes came up.The Kubernetes was one thing that we can even deploy it to bare metal or we can still have — even we can deploy mini shift on raspberry pi. That was one thing that we spent time on and elastic container services from Amazon because our project was an AWS and we preferred to but at that time, ECS was not that mature and the terminologies are architecture we wanted to deploy in containers was not that really full-fledged efficiently going to be deployed on ECS. After like when we, I know ECS, then we shift it to trying out Kubernetes and this is where like Kubernetes seem to be in a great option over ECS. That was a time like we decided not to go with ECS.[[This is good transfer, AWS when if they can come up with Kubernetes as in service and a product. I don’t know how they will managed either ECS or Kubernetes as in service but it would be interesting.But on lines of that, we have some other place like Stratoscale and tectonic from CoreOS. Initially, CoreOs was a big major part in Kubernetes as of now also it is, but they offer tectonic as in service for Kubernetes so yeah, with the joining of AWS into CNCF foundation, we can expect something like that.But I don’t think like that is the only case, we need to have Kubernetes as in service from AWS. So it would be just kind of automation from point of cluster scaling but the issues like, which the native applications face, those will not be addressed and I don’t think that would be a great success. When we look at Google container engine, what is that? It is a container service from Google on top of Kubernetes. But nowadays, people don’t prefer to be a vendor lock in kind of thing.[[[This thing I wanted to discuss about is like after you picked up Kubernetes, what other things do you have to do to get started with integrating with Kubernetes and how exactly did you map the whole Kubernetes along with the existing development cycle?[The first challenge was like dockerizing our, all the four models of application. So basically they were using Ruby on Rails. So we started off with dockerizing and building it an image. So, after that, the second challenge or the second choice was like which Docker image registry to choose and how to build automatically images for Docker. That one was basically addressed by Vishal and he can put up more light on like how we automated our building image pipeline for our application.[Initially, we tried to manually build the image and also did not worry about how much time it takes to build that image. With some experience, we then optimized the image building logic. Then the next challenge was…[[[[On both of those, if we build that image due to resource constraints, it was taking so much time and the image building logic that they have is kind of sequential, you cannot build two image at the same time. So ultimately, we found that it was not working as intended so instead of building on Docker Cloud, we thought of building it ourselves and then we decided to use Jenkins to build the images on our own service.In that case, with the help of some optimizations in Docker Cloud, we were able to reduce that time to just five to six minutes.[[So it self-supports these things but as a platform the Docker Hub as well as Docker Cloud were not respecting these things too much and probably were making the image building process was taking so much time.[[[[And Docker will assume that that package is different or that line is from different checks. In that case it will expire or bust the previous cache and after that what the lines, which you had in your Docker file will be run over again. So ideally I don’t need to place all of those lines or all of those commands or whatever you need to be placed in Docker file, the things shouldn’t be dynamic. It should not actually expire the cache somehow.[[[[So it is not necessary to have just one Docker file. You can have multiple Docker files and have multiple base images actually. Just to ensure that the base image that you are using is not – I mean it does not contain any dynamic logic like setting up the environment that it was dynamically or adding context to build context like they use those colors or something like that. It shouldn’t be dynamic. So in that case you can use base image.[[So once our image building was done, we wanted to [provisional] Kubernetes cluster with high level ability and secure. So we come across different things like Kubeadm, KubeSpray and Kops. So we choose Kops, it was where you can incubate your project from Kubernetes itself and it is built on top of Terraform which provisions Kubernetes cluster are on top of AWS. It can provision it in the private subnet, which is like a secured network cluster and we played with that and we provisioned our play cluster using Kops but thought we had some issues and troubleshooting things.But for our initial try route, we were using Kops 1.5 and Kubernetes I think it was at that time, it was just support. Kops was supporting Kubernetes 1.4. So after that, the one important part was also scaling the cluster then also scaling apps, monitoring the cluster and after alerting the system resources if one of your service is down, if one of your nodes is down notify to developers and your ops people.So this latest thinking about for monitoring we chose ELK. That is Elasticsearch, Logstash and Kibana, which worked out of the box and it came up as an add on from Kubernetes community itself. But for monitoring we thought of Prometheus and Using prometheus with Grafana. So we clubbed all of those things together and after that, we started to look into the core application performance and scaling issues like auto scaling nodes. So for that, running Kubernetes cluster on AWS with Kops doesn’t have an auto scaler functionality.We had to implement cluster auto-scalers to specify your minimum or maximum limits and using that, you can auto-scale up and down your limit. The other important thing, what we do is segregating the apps using labels and name spaces. So in our traditional architecture let’s say our client was adding one new app and he was adding it on two servers, maybe one is front and other is back end somewhere and that enrolment course completely segregated.But when you run your apps across the clusters, maybe a Kubernetes cluster, you afford, we don’t have control like where is our afford shielded. Let’s say our four containers are running on four different systems and when our –[[We have our front and back end boards and services and this is how we segregate but apart from that, our node allocations is still not in our control. So there is something called leveling concept from Kubernetes or where we can level the nodes or physical machines. Say this app is equal to XYZ and we will specify that to label in our port manifest or deployment manifest. So that our port is scheduled to run on that particular node, which matches the label. So this is some things like that made the deployment cycle easy.[Apart from that, we will be continuing the discussion about how exactly all of these layers that we just discussed in our next podcast. So any final words Rahul?[Because using your Route 53 service discovery mechanism, Kops provisions the cluster and API communication happens and it will automatically allocates and registers domains. So VPC and DNS are important things if you are trying to explore Kubernetes or pro-agent Kubernetes cluster on AWS using kops.[[Another challenge is setting up the Kubernetes cluster itself. So there are multiple tools Rahul has discussed Kops in more detail. So we will discuss it in the next podcast. Other challenges are maintaining the manifest files, which are needed to cleared resources or resources on the Kubernetes for the deployments for services and whatnot. So you’ll need to either check in those files or need an internet tool or a custom tool to at least hold those files and some way to modify those files and apply on Kubernetes in order to supervise the changes.Or actually, the ruling deployment of the changes that you made. Other challenge is related to authorization and security like who can access and what role. Like name spaces and there are multiple things. Also, I just missed out, Kubernetes is just for production or to start working on a kind of server thing but on local units some way to use it on your development machine. So for that unit some different techniques to orchestrate the Docker images on your local machine. So I guess we’ll discuss this in more details next time. But yeah, these are the thoughts from my end.[Yeah, moreover also using the internal tools for managing your manifests and other things as well as how all of these things you add up in your own tool when you are deploying it. For example, I believe you are doing a range application deployment, how exactly that develops in your application. Again, thanks Rahul and Vishal. That’s it for this episode. Thanks.[[[END]