1 00:00:07,390 --> 00:00:09,300 After watching this video, you will be able 2 00:00:09,300 --> 00:00:13,510 to define infrastructure as code, describe ephemeral infrastructure, and 3 00:00:13,510 --> 00:00:17,119 describe immutable delivery via containers. 4 00:00:17,119 --> 00:00:21,700 Infrastructure as code is the practice of describing infrastructure in textual format. 5 00:00:21,700 --> 00:00:24,460 I’m not talking about documentation here. 6 00:00:24,460 --> 00:00:30,070 I’m talking about a textual format that is executable, otherwise known as code. 7 00:00:30,070 --> 00:00:34,620 You want to be able to configure your infrastructure using a textual description that you can give 8 00:00:34,620 --> 00:00:36,620 to a tool to execute. 9 00:00:36,620 --> 00:00:40,760 The tools that make this possible are called configuration management systems. 10 00:00:40,760 --> 00:00:44,850 These are tools like Ansible, Puppet, Chef that allow you to describe your infrastructure 11 00:00:44,850 --> 00:00:49,810 as code, and then create that infrastructure and keep it in that state. 12 00:00:49,810 --> 00:00:54,609 You never want to perform system changes on software configurations manually. 13 00:00:54,609 --> 00:00:58,660 This is not reproducible and it's extremely error prone. 14 00:00:58,660 --> 00:01:02,480 You want to use templates and scripts that describe how to install and automatically 15 00:01:02,480 --> 00:01:07,340 configure elements such as systems, and devices, and software, and users. 16 00:01:07,340 --> 00:01:11,880 Then you can take that textual code and store it in your version control system so that 17 00:01:11,880 --> 00:01:14,640 you have a history of all of the changes. 18 00:01:14,640 --> 00:01:18,890 This way everyone knows which version is the latest version and how the infrastructure 19 00:01:18,890 --> 00:01:20,280 should look. 20 00:01:20,280 --> 00:01:24,890 Technology like Docker, and Vagrant, and Terraform, and even Kubernetes, also allow you to describe 21 00:01:24,890 --> 00:01:30,799 your infrastructure as code, and this code should be checked into version control. 22 00:01:30,799 --> 00:01:35,920 The reason this is so important is because server drift is a major source of failure. 23 00:01:35,920 --> 00:01:40,560 Over time, servers get updated for various reasons, and not always by the same people. 24 00:01:40,560 --> 00:01:43,829 This causes them to drift from their original configuration. 25 00:01:43,829 --> 00:01:48,159 Sometimes the accumulation of these changes cause failures in unpredictable ways. 26 00:01:48,159 --> 00:01:52,220 Even worse is having servers that are supposed to be the same, but one of them 27 00:01:52,220 --> 00:01:55,549 keeps failing due to a misconfiguration somewhere. 28 00:01:55,549 --> 00:02:00,340 The saying, “Servers are cattle, not pets,” refers to how you treat servers. 29 00:02:00,340 --> 00:02:02,110 Suppose you have a thousand head of cattle. 30 00:02:02,110 --> 00:02:04,750 You don’t take the time to give each one of them a name. 31 00:02:04,750 --> 00:02:08,500 When one of them gets sick you put them out of their misery and replace them with another. 32 00:02:08,589 --> 00:02:12,089 Pets on the other hand? They're lovingly cared for and nursed back to health when they are 33 00:02:12,089 --> 00:02:13,000 sick. 34 00:02:13,088 --> 00:02:18,270 The message is to not lovingly hand-craft servers or spend too much time debugging when 35 00:02:18,270 --> 00:02:19,550 they don’t work. 36 00:02:19,550 --> 00:02:24,379 You want to be able to replace them with an identical server that is working properly. 37 00:02:24,379 --> 00:02:27,750 That means that you must think about your infrastructure as something ephemeral 38 00:02:27,750 --> 00:02:29,550 or transient. 39 00:02:29,550 --> 00:02:32,680 It only exists for the time that you need it and then you remove it when it’s not 40 00:02:32,680 --> 00:02:33,680 being used. 41 00:02:33,680 --> 00:02:36,460 For example, in the past, building test environments took weeks. 42 00:02:36,460 --> 00:02:40,870 So, you would keep them around for months because it took weeks to build them. 43 00:02:40,870 --> 00:02:45,950 But when you have infrastructure as code, it takes minutes to deploy a new set of 44 00:02:45,950 --> 00:02:46,950 servers. 45 00:02:46,950 --> 00:02:50,140 You can bring up a test environment, use it for a period of time and then destroy it. 46 00:02:50,140 --> 00:02:53,459 If you need it again another day, create a new one. 47 00:02:53,459 --> 00:02:55,260 You don’t keep it running forever. 48 00:02:55,260 --> 00:02:58,790 You just bring it up when you need it, you bring it down when you no longer need it. 49 00:02:58,790 --> 00:03:01,370 It's transient. 50 00:03:01,370 --> 00:03:04,290 This also allows us to release through parallel infrastructure. 51 00:03:04,290 --> 00:03:08,680 For example, I can build up a server that looks just like the one that is in production. 52 00:03:08,680 --> 00:03:12,290 I can deploy a new version of an application or monitor it to see if it’s working 53 00:03:12,290 --> 00:03:13,290 correctly. 54 00:03:13,290 --> 00:03:16,990 If it looks like it is behaving correctly, I shut down the one in production, I make 55 00:03:16,990 --> 00:03:19,180 the new one the production server. 56 00:03:19,180 --> 00:03:23,165 With parallel infrastructure I can keep things running constantly. 57 00:03:23,165 --> 00:03:28,537 Infrastructure as code allows me to create identical infrastructure every time. 58 00:03:28,537 --> 00:03:33,319 Ephemeral infrastructure can be used and then discarded because servers are built on demand, 59 00:03:33,319 --> 00:03:37,506 via automation, using infrastructure as code techniques. 60 00:03:37,506 --> 00:03:40,613 Tools, such as Docker, help us create immutable delivery. 61 00:03:40,613 --> 00:03:44,269 Docker is a packaging technology that allows us to bring things up and bring them down 62 00:03:44,269 --> 00:03:49,002 in a consistent fashion, in an isolated environment called a container. 63 00:03:49,002 --> 00:03:53,620 Docker supports infrastructure as code by allowing you to specify how to build the image 64 00:03:53,620 --> 00:03:55,980 from code called a Dockerfile. 65 00:03:55,980 --> 00:04:00,230 These Dockerfiles build the same image in the same way every time. 66 00:04:00,230 --> 00:04:05,280 Docker then creates a container from that image in the same way every time it’s deployed. 67 00:04:05,280 --> 00:04:10,170 This means that the container that is running in production can be run on the developer’s 68 00:04:10,170 --> 00:04:11,170 laptop. 69 00:04:11,170 --> 00:04:14,019 It is the ultimate development-production parity. 70 00:04:14,019 --> 00:04:18,290 This is because all of the dependencies to run the application are packaged together 71 00:04:18,290 --> 00:04:20,030 inside the container. 72 00:04:20,030 --> 00:04:22,830 This limits any variance or possible side effects. 73 00:04:22,830 --> 00:04:27,380 There is nothing else needed except for the container runtime like Docker to run it on. 74 00:04:27,380 --> 00:04:32,320 Tools like Docker also allow you to do rolling updates with immediate roll-back. 75 00:04:32,320 --> 00:04:36,050 Right, you are not installing the application to see if it works and then uninstalling it if 76 00:04:36,050 --> 00:04:37,050 it doesn’t. 77 00:04:37,050 --> 00:04:38,920 You simply bring up a Docker container with the new version. 78 00:04:38,920 --> 00:04:43,750 If it starts misbehaving, you stop it, bring it down, and bring up the previous version which is already 79 00:04:43,750 --> 00:04:45,820 installed in its own container. 80 00:04:45,820 --> 00:04:48,660 It literally takes seconds. 81 00:04:48,660 --> 00:04:51,880 You would treat containers that start misbehaving the same way. 82 00:04:51,880 --> 00:04:54,780 You delete the container, and you create another one to take its place. 83 00:04:54,780 --> 00:04:58,760 The new container is going to be exactly like the old one on the first day it came up. 84 00:04:58,760 --> 00:05:02,700 If there was some kind of corruption, it is going to be clear that corruption will bring the 85 00:05:02,700 --> 00:05:06,420 whole thing back down to its original state. 86 00:05:06,420 --> 00:05:08,250 This is a very different way of working. 87 00:05:08,250 --> 00:05:12,230 You never make changes to running containers like you would a running server. 88 00:05:12,230 --> 00:05:14,670 Remember: “cattle, not pets.” 89 00:05:14,670 --> 00:05:18,260 You don’t patch containers for vulnerabilities or modify them in any way. 90 00:05:18,260 --> 00:05:23,510 To make any change, you make a change to the image that the container was created from. 91 00:05:23,510 --> 00:05:27,650 Then you redeploy the new container to take the place of the old one. 92 00:05:27,650 --> 00:05:32,210 The reason is simple: if you patch a container and it dies, the new one is brought up to 93 00:05:32,210 --> 00:05:35,300 take its place, the new container won’t have the patches. 94 00:05:35,300 --> 00:05:39,310 That’s why it’s imperative that you modify the image. 95 00:05:39,310 --> 00:05:43,930 They are the template for creating the containers and they are the things that must be kept 96 00:05:43,930 --> 00:05:48,210 up to date, not the running containers. 97 00:05:48,210 --> 00:05:52,750 In this video, you learned that infrastructure as code describes infrastructure in an executable 98 00:05:52,750 --> 00:05:54,880 textual format. 99 00:05:54,880 --> 00:05:57,550 Ephemeral infrastructure can be used and then discarded. 100 00:05:57,550 --> 00:06:00,840 Servers are built on demand, via automation. 101 00:06:00,840 --> 00:06:05,221 Rather than patching a running container, immutable delivery is making changes to the 102 00:06:05,221 --> 00:06:09,000 container image, then redeploying a new container.