1. An introduction to immutable infrastructure using Azure DevOps pipelines
Ibon Landa
Luis Fraile
#DevSum19

2. Don’t forget to evaluate this session in the DevSum app!

3. Ibon Landa LF
@ibonilm

4. Luis Fraile @lfraile lfraile@plainconcepts.com IL
Luis has been working around software development for more than ten years. Involving development, analysis, team magement, etc. Luis helps teams to be more effective in their development teams with tools like best practices and agile methodologies. Also he loves to be involved in the creation and developing all aspects of software products with proven experience during my career.
B!Play marketing platform based on digital content
@lfraile

5. Our team IL
We provide full development and design of digital products from start to finish as well as consulting services as requested.
We craft innovative and engaging custom solutions for our partners. That includes multi-platform applications, cloud services, customized backend solutions, desktop clients as well as public and private web portals.

6. Where to find us IL

8. Agenda DevOps Intro Inmutable infrastructure Infrastructure as a Code
Azure DevOps pipelines
Inmutable infrastructure with Docker
Inmutable infrastructure with Virtual Machines LF

9. S4 Solution Specialist Sales Summit
6/17/ :28 AM
“DevOps is development and operations collaboration”
“DevOps is treating your infrastructure as code”
It’s DevOps! LF
It’s DevOps!
“DevOps is using automation”
“DevOps is feature switches”
It’s DevOps!
It’s DevOps!
© 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.
“Scrum for Ops?”
“DevOps is small deployments”

10. What is DevOps?
People. Process. Products.
Build& Test
Deploy
DevOps is the union of people, process, and products to enable continuous delivery of value to your end users.
Donovan Brown (Microsoft) “ ” LF
DevOps is the union of people, process and products to enable the continuous delivery of value to your end customers
Continuous Delivery
Develop
Operate
Plan & Track
Monitor & Learn

11. DevOps Best Practices Version everything Automate everything
Course or module title
Date or rev #
DevOps Best Practices
Version everything
Automate everything
Tokenize configurations
Use one-click deployments
Deploy the same way to every environment
Have always a rollback mechanism in place
Build only once
Lock down the environments … IL
DevOps is a journey and there are couple of DevOps best practices that can help your teams to walk this path
These best practices go beyond common sense; they get at the essence of what DevOps means for your enterprise and how to get DevOps right the first time.
Version everything
Do you exclude from versioning artifacts like databases, configuration files, binaries, documentation, tools or environments?
To determine whether you're versioning everything, the simple question to ask is, "Can I recreate a specific version of the complete software system — with servers, environments, data, software, and configuration — by running one command that gets a specific revision from my version-control system?" If you cannot, you're not versioning everything.
Tokenize configurations
Do you manually copy or change configuration files to match each target environment?
So…
Do you need to remember which configuration files must be changed
Do you make mistakes or omissions when doing these changes?
Are you exposing sensitive information about the environments?
Only build packages once. We want to be sure the thing we’re deploying is the same thing we’ve tested throughout the deployment pipeline, so if a deployment fails we can eliminate the packages as the source of the failure.
Deploy into a Production-like Environment
Forget last-minute surprises!! They can be eliminated and applications can be released safely to production at any time….you test your application that then you deploy it in another enviroments that it´s different, it doesn´t make sense!
Each new deployment should be made into an environment very similar to the actual final production environment.
HP Confidential – For training purposes only

12. Infrastructure

13. Infrastructure can be complexLF
Las apps/infra cambian
Las apps/infra evolucionan
Puede haber múltiples entornos que tiene que ser iguales

14. A regular deployment pipeline

15. A regular deployment pipeline
To produce a release, we need to build it from source
The resulting application deliverable app is…
a single immutable unit
built once and stored in an artifact repository
regenerated by the continuous integration system after every change IL
Let's assume we have an application. To produce a deliverable, we need to build it from source. This involves compiling sources, processing and copying resources, and probably a few more steps.
In its simplest form this process looks like this:
The resulting application deliverable (typically a .jar or .war file for JVM-based apps) isa single immutable unit built once and stored in an artifact repository regenerated by the continuous integration system after every change

16. A regular deployment pipeline
Of couse, it requires a stack of software to execute…
Server application
Language runtime
Libraries OS … IL
The application of course doesn't run directly on bare metal. Whether on your laptop or on a server, it requires a stack of software to execute.
A typical server application requires an app server (embedded in the app or not) and a language runtime (like the JVM). The language runtime itself uses various libraries and runs on top of an OS kernel which drives the hardware.

17. A regular deployment pipeline
There are several machines the app needs to run
The application is gradually promoted from env to env
The same app is pulled from the artifact repository IL
In all but the simplest projects, there are several machines the application needs to run on, organized in multiple environments. The application is gradually promoted from environment to environment. This ensures that what is run in production, is what was tested in test. To achieve this, the same application is pulled from the artifact repository and deployed unchanged to the different machines:
This avoids the classic mistake of building a separate artifact per environment and effectively taking the risk of running something potentially different on all machines.
Yet when we look at the remaining layers of our stack, this is exactly what is happening!

18. A regular deployment pipeline
The job of the system administrator to ensure that these machines are as identical as possible
All changes, patches and upgrades need to be performed on all machines IL
It is the job of the system administrator to ensure that these machines are as identical as possible, yet each is built individually. All changes, patches and upgrades need to be performed on all machines. The sheer complexity of this task and the numerous moving parts make this very difficult to achieve reliably. Even with automated configuration tools and recipes it's easy for some minor detail to slip through the cracks!
So what could potentially go wrong?

19. But sometimes…The system becomes a house of cards
Some additional software is missing
A resource (directory, ...) has been created under the wrong name
The wrong version of some software is installed
Permissions have been set incorrectly a critical resource (port, ...) is occupied
Application code is deployed outside of the normal straight-from-source-control process
The operating system has been patched again and again ….
IL & LF completa
Here is just of short list of issues, most of which you will probably already have encountered:
some additional software is missing
a resource (directory, ...) has been created under the wrong name
the wrong version of some software is installed (usually the old one with the bug)
permissions have been set incorrectly
a critical resource (port, ...) is occupied
If these are the risks, then why aren't we holding our systems to the same standards as our applications by applying the same principles for building them?
Why are we still building works of art and snowflake servers when what we need is an army of clones?

20. At the end of the day …

21. Immutable Infrastructure
The whole machine is now packaged as a single immutable unit
It contains the entire software stack and it is regenerated by the continuous integration server after every change LF
This is where Immutable Infrastructure comes in.
Instead of assembling just the application, the whole machine is now packaged as a single immutable unit. It contains the entire software stack and it is regenerated by the continuous integration server after every change:
Instead of having to worry about updating many moving parts at all layers, the whole Machine Image is now promoted unchanged from Environment to Environment. Effectively finally making sure that what we run in production is what we tested in test.

22. Immutable Infrastructure

23. What is Immutable Infrastructure
Immutable infrastructure is comprised of immutable components that are replaced for every deployment, rather than being updated in-place.
Those components are started from a common image that is built once per deployment and can be tested and validated IL
Immutable simply means something that is created and left unchanged.
it means is that once the image is working, only a working image is deployed

24. Advantages Reduce inconsistency in your infrastructure
It is easy to have a production-like system on development machines
Improve the trust into your deployment process
Rollback to an old version is easy
Every change is in a script
Setting up staging systems is easy and can be automated
Testing the new infrastructure in isolation is possible LF

25. We also need tools!

26. IL
As we spoke before You can’t buy DevOps, as DevOps is not a software, tool, process, company, or person — it’s a methodology.
 There are, however, products & tools that can help enable different DevOps practices and different teams which can be used to make things easier.
DevOps is not a tool or a software, it’s a culture that you can adopt for continuous improvement. It will help you to bring your Developer Team and Operations Team on the same page, allowing them to work together with ease.

27. IL

28. Just our tooling… Microsoft Azure Azure DevOps pipelines Terraform
Docker
Ansible
Packer … IL

29. Azure DevOps pipelines

30. Introducing Azure DevOps
Azure Boards
Azure Pipelines
Azure Repos LF
Deliver value to your users faster using proven agile tools to plan, track, and discuss work across your teams.
Build, test, and deploy with CI/CD that works with any language, platform, and cloud. Connect to GitHub or any other Git provider and deploy continuously.
Get unlimited, cloud-hosted private Git repos and collaborate to build better code with pull requests and advanced file management.
Azure Test Plans
Azure Artifacts 
Test and ship with confidence using manual and exploratory testing tools.
Create, host, and share packages with your team, and add artifacts to your CI/CD pipelines with a single click.

31. Azure Pipelines
Cloud-hosted pipelines for Linux, Windows and macOS, with unlimited minutes for open source
Any language, any platform, any cloud
Build, test, and deploy Node.js, Python, 
Java, PHP, Ruby, C/C++, .NET, Android, and iOS apps. Run in parallel on Linux, macOS, and Windows. Deploy to Azure, AWS, GCP or on-premises LF
Extensible
Explore and implement a wide range of community-built build, test, and deployment tasks, along with hundreds of extensions from Slack to SonarCloud. Support for YAML, reporting and more
Containers and Kubernetes
Easily build and push images to container registries like Docker Hub and Azure Container Registry. Deploy containers to individual hosts or Kubernetes.
Best-in-class for open source
Ensure fast continuous integration/continuous delivery (CI/CD) pipelines for every open source project. Get unlimited build minutes for all open source projects with up to 10 free parallel jobs across Linux, macOS and Windows

32. Demo LF (5 mins) YAML Build artifacts Agents Trigger
Build one => poner foco 1 build & N pipelines
Variables de release
Demo

33. Infrastructure as code

34. Infrastructure as code
Course or module title
Date or rev #
Infrastructure as code
Infrastructure
IT infrastructure consists of all components that somehow play a role in overall IT and IT-enabled operations.
It can be used for internal business operations or developing customer IT or business solutions. 
Code
A set of instructions or statements that are processed by a computer.
Infrastructure as code
Treating your infrastructure as code to ensure that is as versionable, repeatable, and testable as application code IL
So….automate your environments!!
The environment for your application is typically made up of many components – maybe a virtual machine, storage account, and virtual network, or a web app, database, database server, and 3rd party services….whatever..
Iac/Terraform enables you to work with the resources in your solution as a group. You can deploy, update, or delete all the resources for your solution in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging, and production.
So creating a template we can version it as any other artifact of the project……do you remember? Version everything! So it´s very easy to create the required environment at any time and of course by anyone.
HP Confidential – For training purposes only

35. Benefits Avoid deployment inconsistencies Speed and simplicity
Configuration consistency
Minimization of risk
Increased efficiency in software development
Cost savings IL

36. What is Terraform
A tool for… “Write, Plan, and Create Infrastructure as Code”
Open Source, created by Hashicorp (vagrant, packer…)
A tool to manage virtual server life cycles (AWS, Azure, VMWare, OpenStack, Google cloud, Heroku, Kubernetes etc…)
A tool to manage supporting services (DNS, ..)
Readable and writable
Written in Go
Pluggable
Multiplatform LF

37. Resources (Azure) resource "azurerm_resource_group" "test" {
name = "example-resources"
location = "West Europe" }
resource "azurerm_app_service_plan" "test" {
name = "example-appserviceplan"
location = "${azurerm_resource_group.test.location}"
resource_group_name = "${azurerm_resource_group.test.name}"
sku {
tier = "Standard"
size = "S1"
resource "azurerm_app_service" "test" {
name = "example-app-service“ // Globally unique name here!!
app_service_plan_id = "${azurerm_app_service_plan.test.id}" LF

38. Resources (Amazon)
resource "aws_elastic_beanstalk_application" "tftest" {
name = "tf-test-name"
description = "tf-test-desc" }
resource "aws_elastic_beanstalk_environment" "tfenvtest" {
name = "tf-test-name"
application = "${aws_elastic_beanstalk_application.tftest.name}"
solution_stack_name = "64bit Amazon Linux v4.8.1 running Node.js" LF

39. LF
Enseñar repo/artefacto/tarea de release.
Demo

40. Immutable Infrastructure with Docker

41. Immutable infrastructure with DockerIL

42. Version everything!! LF

43. Build & Publish docker images to ACRLF

44. Deploy to several environments

45. Deploy the same artifacts / the same way

46. IL
Demo

47. Immutable Infrastructure with Virtual Machines

48. Ansible, Packer & TerraformLF

49. Packer
Packer is a tool for creating machine and container images for multiple platforms from a single source configuration IL
Packer & Azure
Easy to automate the creation of custom images
Installs and configures software at build time
Single config file to create custom images
Support for multiple platforms
Embraces modern configuration management
And more…

50. Packer Template IL

51. Immutable infrastructureIL
DevOps commit code or configuration change
VSTS Build builds and packages application
VSTS Release invokes Packer to build a Linux image and store it in Managed Disks
Packer invokes the Ansible Playbook provisioner to install JDK, Tomcat and SpringBoot application
VSTS Release invokes Terraform to provision Infrastructure and uses Packer build image

52. Continuous integration build definitions
Apply the configuration using Ansible
Create the images using Packer templates
Publish generated images IL

53. Deploy to several environments
Apply the configuration using Ansible
Create the images using Packer templates
Publish generated images IL

55. And…. Last but not least – don’t forget to evaluate this session in the DevSum app!

57. Where to find us