 Hello, welcome to Microsoft Build 2017, and welcome to the session on OSS-based DevOps. In part one, I will talk about CI CD with Jenkins and Netflix Technologies. In part two, my colleague Eugene will talk about provisioning using Terraform. So let's get started. When developers try to do DevOps with Azure, they typically come to a fork in the road. Visual Studio Team Services provides a fully managed service with excellent integrations into Azure. However, Cloud-native and Enterprise Java developers also want third-party tools they know and love to work with Azure. In this talk, I'll go through some of the OSS tools you see here on the right, and show you how to integrate them with Azure. Let's start with Jenkins. Jenkins is a very popular DevOps tool for continuous integration or CI. So what is CI? It is the DevOps practice of merging all developer working copies to a shared mainline or trunk ideally several times a day. This is achieved by building and testing developers changes on-commit via automation. One of the problems with CI is that as the codebase and the automation increases, the CI gets slower and it becomes a bottleneck. To address this, we released the Azure VM agents plugin with Jenkins. This plugin lets Jenkins rapidly spin up large numbers of Azure VMs in parallel, thus making CI faster and also cheaper, as these VMs are quickly torn down when not needed. Unlike on-premise machines, so you only pay for what you use. So let me show you how this works. To start with, all you need to do is get to this ak.ms-urai and click Deploy to Azure. This will bring you to the screen, which will help you to spin up a Jenkins instance on Azure using an SSH key. So all you need here is a name for your resource group, a username, and a SSH public key for which you have a secret key, and then the Jenkins DNS prefix, and you're good to go. Once you've done this and you've configured your Jenkins instance, you will now get to a screen for configuring your system that looks like this. At this point, you don't need to install any additional plugins because we have installed all the plugins you need for you. The most important one that I'm talking about right now is the one that you need to do your CI. This is the Microsoft Azure VM agents plugin. This relies on the Azure credentials plugin, so that where you can basically plonk in your service principle and service principle secret, that will let Jenkins master know how to access Azure resources so that it can go and provision VMs as it needs. The other thing you need to do is to define what is the template of your VM agent look like, so that every time Jenkins wants to instantiate a VM, you need to tell it what are the different criteria for it to instantiate it. So for example, it'll have things such as size, but also you can define either an image reference to something from the marketplace or create your own custom user image from a baked VHD, say using something like Packer. That's it. So once you save this, any developer using your Jenkins master within any job, all he needs to do is to say, restrict where this project can be run, check this box, and use the label expression for the template that he needs, and every time he runs this job, Jenkins will decide to spin up or tear down Azure VMs depending on the load that it needs. So this automatically scales up and down, and think of it as a domain-specific, CI-specific autoscaler. So this is so trivial and easy to configure that we use it a lot ourselves. For example, we use this heavily for all of the builds and CI that you see for.NET Core. As you can see here, in the recent past, we have been spinning up something like 240 plus virtual machines, and with this level of parallelization and scale, we are able to bring, we have brought down our CI times from something like two hours initially to less than 15 minutes now. So this is compelling that this is also used by Jenkins itself. So the Jenkins OSS project is built on Azure so every time you check in something into Jenkins, it spins up a CI on Azure which use the exact same plugin. So if you do not want to use our QuickStart template with the master installed on Azure, you also have the choice of using the Azure VM agents plugin from your own on-premise master. So if you have a Jenkins server, all you need to do is look for this Azure VM agents and follow the instructions in this page and you're good to go. What if you wanted to use the Jenkins instance on Azure but you want to tune it yourself? So there are two options here. One is you can secure the Jenkins instance on Azure using the guidance in this blog post that you can get to from this link, or you can just fork our QuickStart template because it's fully open source and tune it to your specific needs. So let me get back to the slides. So now that you have seen how to do continuous integration, let's move on to the next important practice in the typical DevOps lifecycle, which is a notion of continuous deployment or CD. So what is CD? CD is nothing but the continuation of CI. So it is not for everyone or every project, but if implemented right, it can drastically improve business agility. CD relies heavily on automation of all steps and tasks in a release pipeline. The initial effort of setting up this automation can seem overwhelming, but it'll save a lot of headaches and effort going forward. Some of this automation, the initial effort can be mitigated by the notion of immutable pipelines. This is the concept where production infrastructure is treated as cattle which can all be treated equally rather than pets that need to be individually cared for via patching and upgrading. The company that pioneered the concept of immutable infrastructure even before Docker popularized it with containers is Netflix. They use an immutable pipeline tool called Spinnaker to enforce this best practice. In order to achieve immutable pipelines, we have built out a tool chain based on OSS tools combined with auto-scaling Azure services. So everything I will show you is completely free software except for the basic cost of Azure compute to run them. If you have an application that you haven't containerized, you can deploy to auto-scaling sets of virtual machines using Azure virtual machine scale sets. We worked with HashiCorp to extend Packer, which is an OSS tool to bake both Windows and Linux Azure VHDs efficiently. However, if you do have a containerized app, we can bake the image using a Docker plugin in Jenkins, and deploy it to the Azure Container Service Kubernetes. So in this demo, I'll show you this tool chain, the latter tool chain, which will help you to continuously deploy to Kubernetes. So switching back to demo. Before I go into the details, the one thing you need to notice here is that we have a blue screen with a Hello Kubernetes. I'm going to go ahead and kick start a change to this screen. Say, instead of blue, I'm going to say I want green, and I want to say hello build on 17. Let me go ahead and commit this. As that's going on, let's talk about how to spin up an environment that will help you do the tool chain that I showed you. Again, it's pretty straightforward. All you need to do is go to this link, which gives you a quick start template, where you would click deploy to Azure, and then you would go ahead and notice the there are the same kind of parameters you saw earlier, except you can also specify the service principle and the secret right here, and you can also specify the git repository from which you're triggering the continuous deployment, and the name of the image in the Docker repository. Step two is basically to have a Docker build. As you can see that that build already kicked off, which uses a GitHub plugin to listen to that the commit, builds the Docker image and pushes that Docker image to the Azure Container Registry. The Azure Container Registry is nothing but a private Docker registry that sits in your own Azure subscription. Next, we go on to the Spinnaker instance, which I'll spun up for you, which is listening to the changes to that registry. Basically, the pipeline here is listening to changes to the Docker registry of the specific image that we talked about. We have now integrated the CI system and the big system with the CD system. Next, once the pipeline is aware that something has been triggered, it starts running. Here you see the pipeline that is triggered from the Docker registry that we just talked about, and it's initially going to be deploying to a Dev cluster, and then it'll halt at the manual judgment just because this is a demo. One of the things that you can see here is once it's successful, we can basically do a find image from the same Dev cluster and then deploy it to Prod. So the advantage of that is that you don't have to go back to the registry in order to read the changes. That's one of the big benefits of the immutable concept, is that you can have any number of applications go through the exact same flow. As you can see, there's nothing specific to any application here. This is more like a pipeline that you can configure and reuse as a template. So as you can see, this has currently stopped at the manual judgment, but it's asking me to verify whether the Dev server group looks good. I'm already running a proxy system here for my cube control and I will navigate to this URL to test that things have changed. So everything worked well. I should see the Dev cluster has been deployed with the new container and I should see this turn green. Yes, so that worked. So all that this is showing you is the ability for you to control a simple continuous deployment to Kubernetes. However, Spinnaker is not just about that. It also lets you manage the clusters, such as your Dev cluster and your production cluster, and provides you a whole bunch of functionality such as rollback, which is something that is really hard to do in a non-immutable system because now all you need to do is switch back to one of the previous versions that were deployed. It also lets you resize dynamically and scale up and scale down as you want, and also we have attached auto scalers to it based on CPU and memory, as well as things like disable and destroy. These are really important because Spinnaker is also the platform on which something like Chaos Monkey is built. So Chaos Monkey 2.0 basically relies on this cluster view in order for you to do things like fault injection. So let me go back to the deck. So in this demo, I've shown you how trivial it is to create a tool chain that lets you, with a single click and a few parameters, instantly deploy a tool chain using GitHub, Jenkins, Docker, and Spinnaker, along with Azure Container Registry and Azure Container Service. You can choose to run the Jenkins jobs in VM agents, or also use containerized agents with the Kubernetes plugin targeting the same ACS Kubernetes cluster that we created. So all the links that I showed in the demos are provided in this slide along with links to deep dive videos around each step. So I encourage you to go and try these. Please do let us know if you have any questions as you use these tools. We take customer feedback very seriously, and we'll try to help you out as best we can. Please don't forget to view part two of this talk. That's all about Infra as code and provisioning Azure resources using Terraform. Goodbye, and thanks.