WEBVTT
1
00:00:00.210 --> 00:00:01.290
In this lesson,
2
00:00:01.290 --> 00:00:04.050
we will learn about cloud automation.
3
00:00:04.050 --> 00:00:08.250
Cloud automation uses tools and processes to manage,
4
00:00:08.250 --> 00:00:11.250
deploy, and secure cloud resources
5
00:00:11.250 --> 00:00:13.620
and applications efficiently.
6
00:00:13.620 --> 00:00:17.580
Cloud automation concepts include containerization
7
00:00:17.580 --> 00:00:21.235
and Infrastructure as Code or IaC.
8
00:00:21.235 --> 00:00:24.840
Containerization allows applications to be packaged
9
00:00:24.840 --> 00:00:26.610
with their dependencies
10
00:00:26.610 --> 00:00:29.580
into isolated units called containers,
11
00:00:29.580 --> 00:00:31.980
ensuring operational consistency
12
00:00:31.980 --> 00:00:34.080
across different environments.
13
00:00:34.080 --> 00:00:37.830
Infrastructure as Code or IaC is a practice
14
00:00:37.830 --> 00:00:41.100
where infrastructure configurations are defined
15
00:00:41.100 --> 00:00:42.870
and managed through code,
16
00:00:42.870 --> 00:00:45.870
enabling consistent and repeatable deployments
17
00:00:45.870 --> 00:00:47.790
of cloud resources.
18
00:00:47.790 --> 00:00:50.370
Let's learn more about containerization
19
00:00:50.370 --> 00:00:52.860
and Infrastructure as Code.
20
00:00:52.860 --> 00:00:55.388
First, we have containerization.
21
00:00:55.388 --> 00:00:58.740
Containerization is a type of virtualization
22
00:00:58.740 --> 00:01:00.990
in which the host operating system
23
00:01:00.990 --> 00:01:04.710
creates separate environments for each application.
24
00:01:04.710 --> 00:01:06.180
In this construction,
25
00:01:06.180 --> 00:01:09.420
applications are packaged with their dependencies
26
00:01:09.420 --> 00:01:12.330
into isolated units called containers,
27
00:01:12.330 --> 00:01:14.520
ensuring consistent operation
28
00:01:14.520 --> 00:01:18.960
across different operating system or OS environments.
29
00:01:18.960 --> 00:01:21.060
How is this different from Type 1
30
00:01:21.060 --> 00:01:22.980
and Type 2 virtualization?
31
00:01:22.980 --> 00:01:25.110
Well, containerization differs
32
00:01:25.110 --> 00:01:27.120
from traditional virtualization
33
00:01:27.120 --> 00:01:30.900
by isolating resources at the operating system level
34
00:01:30.900 --> 00:01:33.090
rather than the hardware level.
35
00:01:33.090 --> 00:01:35.190
In traditional virtualization,
36
00:01:35.190 --> 00:01:36.660
each virtual machine
37
00:01:36.660 --> 00:01:40.440
is its own isolated operating system instance,
38
00:01:40.440 --> 00:01:41.820
requiring the storage
39
00:01:41.820 --> 00:01:46.230
and processing resources of a full operating system.
40
00:01:46.230 --> 00:01:48.330
Containers, by contrast,
41
00:01:48.330 --> 00:01:50.400
share the host operating system
42
00:01:50.400 --> 00:01:53.670
and isolate only the applications themselves,
43
00:01:53.670 --> 00:01:57.000
making them lightweight and resource-efficient.
44
00:01:57.000 --> 00:02:01.200
Next, containerization uses a containerization engine
45
00:02:01.200 --> 00:02:02.820
instead of a hypervisor
46
00:02:02.820 --> 00:02:05.760
as found in traditional virtualization.
47
00:02:05.760 --> 00:02:10.170
Today, containerization is widely used on Linux servers,
48
00:02:10.170 --> 00:02:12.660
supported by containerization engines,
49
00:02:12.660 --> 00:02:17.660
such as Docker, Kubernetes, Parallels Virtuozzo, and OpenVZ
50
00:02:18.390 --> 00:02:21.780
But how does containerization actually work?
51
00:02:21.780 --> 00:02:24.180
Imagine a standard hardware machine
52
00:02:24.180 --> 00:02:27.330
with a Linux operating system installed on it.
53
00:02:27.330 --> 00:02:29.730
Within the Linux operating system,
54
00:02:29.730 --> 00:02:33.150
we can add a containerization engine, like Docker.
55
00:02:33.150 --> 00:02:34.800
This engine can create
56
00:02:34.800 --> 00:02:37.050
and manage multiple containers,
57
00:02:37.050 --> 00:02:39.690
each containing its own application,
58
00:02:39.690 --> 00:02:41.010
while being supported
59
00:02:41.010 --> 00:02:44.310
by the Linux host operating system files.
60
00:02:44.310 --> 00:02:45.990
In this configuration,
61
00:02:45.990 --> 00:02:49.020
each container acts as an isolated unit,
62
00:02:49.020 --> 00:02:52.350
meaning they are logically separate from one another
63
00:02:52.350 --> 00:02:55.260
and cannot communicate directly by default.
64
00:02:55.260 --> 00:02:58.020
So if two containers need to interact,
65
00:02:58.020 --> 00:03:00.450
they must go through a virtual network
66
00:03:00.450 --> 00:03:02.160
with appropriate routing.
67
00:03:02.160 --> 00:03:06.270
This isolation enhances security and efficiency
68
00:03:06.270 --> 00:03:10.020
by keeping each container's environment distinct.
69
00:03:10.020 --> 00:03:13.140
Importantly, each container also includes
70
00:03:13.140 --> 00:03:16.380
all the dependencies it needs to run,
71
00:03:16.380 --> 00:03:19.770
independent of the host operating system's
72
00:03:19.770 --> 00:03:21.750
installed dependencies.
73
00:03:21.750 --> 00:03:25.110
This ensures that a container will run the same way
74
00:03:25.110 --> 00:03:26.850
on any machine,
75
00:03:26.850 --> 00:03:29.400
regardless of the dependencies present
76
00:03:29.400 --> 00:03:31.590
on the host operating system.
77
00:03:31.590 --> 00:03:36.000
Second, we have Infrastructure as Code or IaC.
78
00:03:36.000 --> 00:03:39.660
IaC is an approach to infrastructure management,
79
00:03:39.660 --> 00:03:41.550
where infrastructure components,
80
00:03:41.550 --> 00:03:44.460
like networks, servers, and storage,
81
00:03:44.460 --> 00:03:47.400
are configured and provisioned using code.
82
00:03:47.400 --> 00:03:49.650
In Infrastructure as Code,
83
00:03:49.650 --> 00:03:52.440
configurations are written as code,
84
00:03:52.440 --> 00:03:53.940
often using languages,
85
00:03:53.940 --> 00:03:57.326
like JavaScript Object Notation or JSON
86
00:03:57.326 --> 00:04:00.030
YAML or Yet Another Markup Language,
87
00:04:00.030 --> 00:04:02.730
and implemented through specialized tools,
88
00:04:02.730 --> 00:04:06.750
such as Terraform, CloudFormation, or Ansible.
89
00:04:06.750 --> 00:04:08.820
This coding approach ensures
90
00:04:08.820 --> 00:04:13.020
that infrastructure setups are consistent, repeatable,
91
00:04:13.020 --> 00:04:16.620
and easy to manage across different environments.
92
00:04:16.620 --> 00:04:20.580
But how is Infrastructure as Code different
93
00:04:20.580 --> 00:04:23.370
from traditional manual configuration?
94
00:04:23.370 --> 00:04:25.830
Well, unlike traditional setups
95
00:04:25.830 --> 00:04:29.370
where admins manually configure the infrastructure,
96
00:04:29.370 --> 00:04:33.750
Infrastructure as Code treats infrastructure as software,
97
00:04:33.750 --> 00:04:37.200
allowing automation of the entire process.
98
00:04:37.200 --> 00:04:41.280
This way, Infrastructure as Code or IaC
99
00:04:41.280 --> 00:04:43.320
shifts infrastructure management
100
00:04:43.320 --> 00:04:46.680
from a labor-intensive, error-prone task
101
00:04:46.680 --> 00:04:51.680
to one that is efficient, controlled, versionable, and fast.
102
00:04:52.230 --> 00:04:54.150
In a traditional setup,
103
00:04:54.150 --> 00:04:57.180
provisioning infrastructure might require logging
104
00:04:57.180 --> 00:04:59.430
into each server separately
105
00:04:59.430 --> 00:05:01.770
and configuring them one by one,
106
00:05:01.770 --> 00:05:05.340
which is time-consuming and prone to errors.
107
00:05:05.340 --> 00:05:07.350
With IaC, however,
108
00:05:07.350 --> 00:05:11.280
you can define the entire setup in code just once
109
00:05:11.280 --> 00:05:14.850
and then use that code to automatically deploy
110
00:05:14.850 --> 00:05:16.650
and configure servers
111
00:05:16.650 --> 00:05:20.340
across multiple environments in seconds.
112
00:05:20.340 --> 00:05:25.340
Next, IaC relies on infrastructure automation tools
113
00:05:25.500 --> 00:05:28.920
rather than direct management by administrators.
114
00:05:28.920 --> 00:05:31.410
Today, Infrastructure as Code
115
00:05:31.410 --> 00:05:35.760
or IaC is commonly used on cloud platforms,
116
00:05:35.760 --> 00:05:37.050
supported by tools,
117
00:05:37.050 --> 00:05:40.492
such as Terraform, for multi-cloud setups,
118
00:05:40.492 --> 00:05:44.790
AWS CloudFormation for AWS resources,
119
00:05:44.790 --> 00:05:48.030
and Ansible for configuration management.
120
00:05:48.030 --> 00:05:51.540
But how does IaC actually work?
121
00:05:51.540 --> 00:05:56.250
Well, imagine you need to set up a multi-tier application
122
00:05:56.250 --> 00:05:58.440
across multiple servers.
123
00:05:58.440 --> 00:06:01.500
Instead of manually configuring each server,
124
00:06:01.500 --> 00:06:04.380
you write a YAML configuration file,
125
00:06:04.380 --> 00:06:07.830
specifying the infrastructure components you need,
126
00:06:07.830 --> 00:06:10.260
such as the server instances,
127
00:06:10.260 --> 00:06:13.110
databases, and networking rules.
128
00:06:13.110 --> 00:06:15.960
This configuration file is then run
129
00:06:15.960 --> 00:06:18.450
through an Infrastructure as Code tool,
130
00:06:18.450 --> 00:06:20.790
like AWS CloudFormation,
131
00:06:20.790 --> 00:06:22.770
which provisions and configures
132
00:06:22.770 --> 00:06:25.170
all the resources automatically
133
00:06:25.170 --> 00:06:28.110
according to your configuration file.
134
00:06:28.110 --> 00:06:30.450
This is Infrastructure as Code.
135
00:06:30.450 --> 00:06:34.530
Importantly, IaC also enables version control
136
00:06:34.530 --> 00:06:36.120
for the infrastructure,
137
00:06:36.120 --> 00:06:38.490
just like with software code,
138
00:06:38.490 --> 00:06:41.370
This means that every change is tracked,
139
00:06:41.370 --> 00:06:46.170
allowing teams to roll back configurations if issues arise.
140
00:06:46.170 --> 00:06:48.480
So with IaC,
141
00:06:48.480 --> 00:06:52.200
updates and adjustments to infrastructure are as simple
142
00:06:52.200 --> 00:06:55.710
as modifying the code and reapplying it,
143
00:06:55.710 --> 00:06:58.560
providing a controlled, predictable way
144
00:06:58.560 --> 00:07:02.760
to manage resources across various environments.
145
00:07:02.760 --> 00:07:04.770
Let's conduct a demonstration
146
00:07:04.770 --> 00:07:09.060
of an nginx web server being deployed as a container,
147
00:07:09.060 --> 00:07:12.990
supported by the Docker Containerization Engine.
148
00:07:12.990 --> 00:07:14.730
In this demonstration,
149
00:07:14.730 --> 00:07:17.790
let's first confirm that Docker is installed
150
00:07:17.790 --> 00:07:20.670
and running on this Kali Linux machine
151
00:07:20.670 --> 00:07:22.380
by checking the version.
152
00:07:22.380 --> 00:07:26.250
We'll do this with the docker --version command.
153
00:07:26.250 --> 00:07:28.500
Yep, Docker is installed.
154
00:07:28.500 --> 00:07:33.360
Now we need to pull the nginx image from the Docker Hub.
155
00:07:33.360 --> 00:07:34.193
We'll do this
156
00:07:34.193 --> 00:07:38.783
with the command sudo docker pull nginx.
157
00:07:40.380 --> 00:07:44.190
It's now downloading the image to our local system.
158
00:07:44.190 --> 00:07:45.450
We can take a look at that
159
00:07:45.450 --> 00:07:49.470
with the command sudo docker images,
160
00:07:49.470 --> 00:07:53.340
and we can see that the nginx image is now located
161
00:07:53.340 --> 00:07:55.800
in our local repository.
162
00:07:55.800 --> 00:08:00.800
Our next step is starting up an instance of nginx.
163
00:08:01.290 --> 00:08:04.113
We'll do that with the following command.
164
00:08:06.480 --> 00:08:09.997
We'll use sudo docker run -d -p 8080:80
165
00:08:13.825 --> 00:08:15.870
-name securityx,
166
00:08:15.870 --> 00:08:18.210
which will be the name of our instance,
167
00:08:18.210 --> 00:08:22.890
and nginx, which refers to the image in our repository.
168
00:08:22.890 --> 00:08:27.890
This command will run nginx on port 80 inside the container
169
00:08:28.680 --> 00:08:33.033
and map it to port 8080 on our host machine.
170
00:08:34.135 --> 00:08:36.303
And it's up and running.
171
00:08:37.140 --> 00:08:39.060
Now let's check it out.
172
00:08:39.060 --> 00:08:42.300
We can first look at the process as it's running
173
00:08:42.300 --> 00:08:46.530
with the sudo docker ps command,
174
00:08:46.530 --> 00:08:47.460
and we can see
175
00:08:47.460 --> 00:08:52.460
that our nginx image is running a specific instance,
176
00:08:53.190 --> 00:08:56.340
but let's go ahead and see it in action.
177
00:08:56.340 --> 00:08:59.280
I'll open up a Mozilla Firefox tab,
178
00:08:59.280 --> 00:09:04.280
and we're going to navigate to http://localhost:8080.
179
00:09:08.820 --> 00:09:09.653
There it is.
180
00:09:09.653 --> 00:09:13.230
We can see the default nginx welcome page,
181
00:09:13.230 --> 00:09:15.900
confirming that the web server is running
182
00:09:15.900 --> 00:09:17.733
inside our container.
183
00:09:18.630 --> 00:09:22.650
Now let's go ahead and stop the nginx container.
184
00:09:22.650 --> 00:09:27.277
We'll do that with the command sudo docker stop securityx.
185
00:09:39.213 --> 00:09:41.490
And our container has stopped.
186
00:09:41.490 --> 00:09:43.110
We'll confirm that
187
00:09:43.110 --> 00:09:47.763
by looking at the processes, sudo docker ps,
188
00:09:48.840 --> 00:09:52.410
and we can see that there are no processes running.
189
00:09:52.410 --> 00:09:55.800
This is the end of our demonstration.
190
00:09:55.800 --> 00:10:00.800
So remember, cloud automation streamlines the management,
191
00:10:01.410 --> 00:10:06.180
deployment, and security of cloud resources using tools
192
00:10:06.180 --> 00:10:11.180
and processes that create efficiency and consistency.
193
00:10:11.490 --> 00:10:16.320
Two major concepts in cloud automation are containerization
194
00:10:16.320 --> 00:10:19.800
and Infrastructure as Code or IaC.
195
00:10:19.800 --> 00:10:22.800
Containerization packages applications
196
00:10:22.800 --> 00:10:25.080
with all their dependencies
197
00:10:25.080 --> 00:10:28.020
into isolated units called containers,
198
00:10:28.020 --> 00:10:31.050
allowing those containers to run consistently
199
00:10:31.050 --> 00:10:33.570
across multiple environments.
200
00:10:33.570 --> 00:10:36.360
Infrastructure as Code, on the other hand,
201
00:10:36.360 --> 00:10:41.360
uses code to define and manage infrastructure components,
202
00:10:41.490 --> 00:10:44.280
enabling repeatable, consistent,
203
00:10:44.280 --> 00:10:46.170
and fast deployments.
204
00:10:46.170 --> 00:10:48.540
By automating these processes,
205
00:10:48.540 --> 00:10:52.320
cloud automation reduces manual configuration,
206
00:10:52.320 --> 00:10:56.520
minimizes errors, and enhances operational control
207
00:10:56.520 --> 00:10:58.383
across environments.