00:00:03.077 --> 00:00:05.387 We have Maestro, obviously.
00:00:07.257 --> 00:00:11.307 So basically we have set up a city for it.
00:00:12.287 --> 00:00:16.247 So really, all of that comes from the sky.
00:00:18.987 --> 00:00:22.434 So first we just define some like basic variables to use in
00:00:22.434 --> 00:00:25.766 the rest of the place, so the Linux target Windows target
00:00:25.766 --> 00:00:29.385 these are the targets that we passed to rust for what platform
00:00:29.385 --> 00:00:30.477 the compile it for.
00:00:30.987 --> 00:00:36.023 So basically these are called triples, so we have like the
00:00:36.023 --> 00:00:41.230 processor, the operating system and really sure what to call
00:00:41.230 --> 00:00:41.657 that.
00:00:41.747 --> 00:00:46.981 I guess like the maybe like called the underlying library I
00:00:46.981 --> 00:00:50.907 suppose don't really focus too much on that.
00:00:51.147 --> 00:00:55.723 Typically there could be another one for Windows that targets
00:00:55.723 --> 00:01:00.522 using like the MSVC C libraries, but that's just a bit harder to
00:01:00.522 --> 00:01:04.877 get compiled from Linux, so I just stuck with this anyway.
00:01:06.157 --> 00:01:07.337 Just other basic stuff.
00:01:07.347 --> 00:01:12.245 This is a URL that comes from get lab itself, like it's just
00:01:12.245 --> 00:01:15.537 innate to how their packagers sees work.
00:01:15.727 --> 00:01:19.628 It's basically like every project in there are like I
00:01:19.628 --> 00:01:24.324 should say, every repository has its own package registry, so we
00:01:24.324 --> 00:01:28.297 are pushing something to the generic package registry.
00:01:28.767 --> 00:01:32.690 So like not nugget or anything like that, just generic packages
00:01:32.690 --> 00:01:36.612 and Maestro 5 package under the version that is the same as our
00:01:36.612 --> 00:01:37.777 current commit tag.
00:01:38.537 --> 00:01:42.337 Uh, with just taking this Linux package variable that I have and
00:01:42.337 --> 00:01:45.669 there's obviously, like I said, doing that all again for
00:01:45.669 --> 00:01:46.137 Windows.
00:01:48.277 --> 00:01:52.441 So we're running this all off the nightly Docker image, so
00:01:52.441 --> 00:01:56.394 we'll get into like what doctor's doing itself in a few
00:01:56.394 --> 00:02:00.417 minutes when we just look at Docker then before anything
00:02:00.417 --> 00:02:04.017 starts, that doesn't even duplicated, we fix that.
00:02:06.727 --> 00:02:10.689 So we just install some basic stuff that we just need as a
00:02:10.689 --> 00:02:12.167 prerequisite to build.
00:02:13.097 --> 00:02:16.363 I plan to eventually just make an internal image that has all
00:02:16.363 --> 00:02:19.470 this stuff pre run as its own Docker image, so that way we
00:02:19.470 --> 00:02:21.367 also run this for every cicd build.
00:02:22.527 --> 00:02:24.277 But for the moment it works fine.
00:02:24.687 --> 00:02:26.857 Basically, we just need mingw 64.
00:02:27.447 --> 00:02:30.699 This is a cross compilation tool chain which allows us to build
00:02:30.699 --> 00:02:31.817 something for Windows.
00:02:31.827 --> 00:02:35.186 Even though we're on Linux, obviously like the development
00:02:35.186 --> 00:02:38.602 version of Webkit itself, and then build essential just has
00:02:38.602 --> 00:02:40.937 like basic compilers and all that stuff.
00:02:42.427 --> 00:02:45.953 We had our targets that we know we're going to compile for
00:02:45.953 --> 00:02:49.420 particular, we don't need the the Linux one, but just for
00:02:49.420 --> 00:02:50.317 symmetry there.
00:02:51.807 --> 00:02:52.537 So then this.
00:02:52.667 --> 00:02:55.662 This makes sure that rust up, or rather that rust itself, knows
00:02:55.662 --> 00:02:58.377 how to compile for each platform that we're trying to do.
00:02:59.637 --> 00:03:03.933 This is just some internal bookkeeping for Git lab, so it's
00:03:03.933 --> 00:03:08.301 able to make releases, and then this is just a little better
00:03:08.301 --> 00:03:12.597 thing for being able to link or rather compile for Windows.
00:03:13.127 --> 00:03:17.202 So this just makes sure that Rust Cargo knows which linker to
00:03:17.202 --> 00:03:21.540 use for the object files, so the main actual build here, like the
00:03:21.540 --> 00:03:25.879 real meat of it, we only want to run this thing if our commit tag
00:03:25.879 --> 00:03:29.297 is just like 3 integers, followed by whatever else.
00:03:30.877 --> 00:03:35.527 So the way I have the versioning set up is the carpal tunnel.
00:03:35.657 --> 00:03:38.627 So this is like think of a solution file or a csproj file.
00:03:40.077 --> 00:03:43.104 The version I haven't here just hard coded to always be 0.0 dot
00:03:43.104 --> 00:03:44.287 zero, dash local develop.
00:03:45.457 --> 00:03:48.457 That means that I can always tell if a Maestro executable I
00:03:48.457 --> 00:03:51.657 am using was built just from a local, or if it was built from a
00:03:51.657 --> 00:03:54.407 cicd process just by seeing if it's this exact string.
00:03:56.947 --> 00:04:01.438 Uh, so basically what we do is we just use SED stream editor to
00:04:01.438 --> 00:04:05.648 in place updates based on the expression we search for that
00:04:05.648 --> 00:04:09.859 exact string and we replace it with version equals and then
00:04:09.859 --> 00:04:13.157 just the CI commit tag in the cargo toml file.
00:04:13.547 --> 00:04:16.997 So this way, like the actual carpal tunnel, doesn't need to
00:04:16.997 --> 00:04:18.377 know what version it is.
00:04:18.607 --> 00:04:22.277 The version purely comes from the current commit tag.
00:04:24.557 --> 00:04:27.201 Just simplify things overall like you can't forget to do it
00:04:27.201 --> 00:04:28.567 in one place and not the other.
00:04:30.217 --> 00:04:35.407 We built for Linux bullet for Windows and then we go in here.
00:04:35.497 --> 00:04:39.888 We tie it up and then this just uploads that to the package
00:04:39.888 --> 00:04:40.547 registry.
00:04:40.957 --> 00:04:45.010 Do the same thing for Windows and these the blush fails on
00:04:45.010 --> 00:04:49.339 curl basically just mean that if the response code is not like
00:04:49.339 --> 00:04:53.461 some good 200 response that should actually set the overall
00:04:53.461 --> 00:04:56.347 return code of curl itself to be nonzero.
00:04:56.597 --> 00:05:00.090 So it actually counts as a failure and the cicd process
00:05:00.090 --> 00:05:03.709 itself will pick that up as being a failure and it's like
00:05:03.709 --> 00:05:07.577 immediately stop running given error to all somethings wrong.
00:05:10.457 --> 00:05:13.747 Then this parts back in like what GitLab itself controls.
00:05:14.277 --> 00:05:15.867 We tell we want to do it.
00:05:15.877 --> 00:05:16.447 Release.
00:05:16.657 --> 00:05:17.437 Give it the right tag.
00:05:18.627 --> 00:05:20.017 We could give it a better description later.
00:05:20.057 --> 00:05:20.627 Doesn't really matter.
00:05:21.907 --> 00:05:25.027 And then we say that it has certain assets available.
00:05:25.337 --> 00:05:28.147 So we just like give up the name of the Linux package.
00:05:28.717 --> 00:05:32.429 These do have to contain the actual target triple in them,
00:05:32.429 --> 00:05:36.394 otherwise the self update thing that we'll look at in a minute
00:05:36.394 --> 00:05:39.477 here just won't be able to find the right asset.
00:05:40.957 --> 00:05:43.051 And then the URL that we uploaded it to, which just
00:05:43.051 --> 00:05:45.427 happens to be the same thing that we can download it from.
00:05:47.717 --> 00:05:50.527 Yeah, that's really the entire CID process.
00:05:50.857 --> 00:05:57.899 We can see that running here in a second, we open up purse or
00:05:57.899 --> 00:06:00.057 you get lab really.
00:06:04.177 --> 00:06:06.737 OK, good over here.
00:06:08.367 --> 00:06:08.907 Let's see.
00:06:19.037 --> 00:06:20.747 All right, so I just made a change a minute ago.
00:06:20.897 --> 00:06:22.517 You remember I removed that.
00:06:27.327 --> 00:06:29.337 Extra update line that we don't actually need.
00:06:29.627 --> 00:06:32.057 So that's kind of actually just demo CCD.
00:06:42.227 --> 00:06:43.027 Click on Taggart.
00:06:43.037 --> 00:06:50.217 So currently we can see our last tag that we did was for RC20.
00:06:53.467 --> 00:06:56.789 Which accuracy Jeremy and Scarlett have you guys had
00:06:56.789 --> 00:06:58.357 chances to check out 040?
00:06:59.197 --> 00:06:59.917 Any problems with it?
00:07:02.827 --> 00:07:04.217 I I haven't made a new project with yet.
00:07:05.587 --> 00:07:07.857 Alright, I guess we'll stick with our lives for the moment.
00:07:07.967 --> 00:07:13.876 So I'll just go ahead and tag it as just like RC21 and I push it
00:07:13.876 --> 00:07:15.967 up to GitLab with tags.
00:07:16.467 --> 00:07:17.457 That's important to note.
00:07:17.547 --> 00:07:21.018 Git will not by default push new tags, so you have to explicitly
00:07:21.018 --> 00:07:23.207 tell it that you also want to push tags.
00:07:24.137 --> 00:07:26.876 There might be a conflict option you can set, but I just haven't
00:07:26.876 --> 00:07:27.887 bothered to find it yet.
00:07:28.987 --> 00:07:32.337 So press that up and go over here to the pipelines.
00:07:32.347 --> 00:07:32.617 We'll see.
00:07:32.627 --> 00:07:35.647 It's probably already started right now.
00:07:35.657 --> 00:07:39.097 I'm actually running this like with my local as a runner.
00:07:39.327 --> 00:07:43.554 So in a second here, we should be able to see there we can see
00:07:43.554 --> 00:07:46.707 Docker firing up as it starts running CID job.
00:07:47.397 --> 00:07:50.189 Obviously, long term is not going to be my local that's
00:07:50.189 --> 00:07:50.987 running the ICD.
00:07:51.837 --> 00:07:54.210 There's just some breakage with our internal stuff at the
00:07:54.210 --> 00:07:54.497 moment.
00:07:57.747 --> 00:07:58.767 So now I could actually.
00:08:02.297 --> 00:08:02.497 Oops.
00:08:07.337 --> 00:08:10.390 It goes so we can actually watch the log in real time that you
00:08:10.390 --> 00:08:11.747 can also see in the browser.
00:08:11.757 --> 00:08:13.037 This is just a little faster.
00:08:15.387 --> 00:08:20.376 So some sign over packages and this will take a minute, so I'll
00:08:20.376 --> 00:08:23.027 dip back out of this in a second.
00:08:25.337 --> 00:08:28.070 It's running all over different commands, et cetera, et cetera,
00:08:28.070 --> 00:08:28.497 et cetera.
00:08:30.277 --> 00:08:33.897 That's the actual compilation of like in Russland starting there.
00:08:36.507 --> 00:08:41.135 So back over here, the way the automatic updating works is
00:08:41.135 --> 00:08:44.587 there is a project Nate called Self Update.
00:08:47.907 --> 00:08:49.517 And over that up.
00:08:52.147 --> 00:08:56.116 Basically this does all the hard work of interfacing with
00:08:56.116 --> 00:08:58.237 whatever back end has backends.
00:08:58.247 --> 00:09:01.970 Probably GitLab Amazon S3 buckets, git, GitHub et cetera
00:09:01.970 --> 00:09:05.759 to where it can download an archive and then just replace
00:09:05.759 --> 00:09:09.287 the current binary with what it finds in the archive.
00:09:10.987 --> 00:09:13.047 So effectively we've just been update.
00:09:16.147 --> 00:09:16.957 That's all it contained.
00:09:16.967 --> 00:09:20.360 Within the updater bit here, so we have just a couple commands
00:09:20.360 --> 00:09:22.837 show this just gives you the current version.
00:09:23.127 --> 00:09:26.168 Lists will actually reach out to GitLab and ask for it and
00:09:26.168 --> 00:09:29.467 update, and you might be seeing this hard coded personal access
00:09:29.467 --> 00:09:29.777 token.
00:09:30.187 --> 00:09:32.177 Yes, that is a hard coded personal access token.
00:09:32.887 --> 00:09:37.465 It is project scopes and is only like it only has read access to
00:09:37.465 --> 00:09:39.367 the Maestro project itself.
00:09:40.367 --> 00:09:42.447 So for the moment I'm leaving that in there.
00:09:42.827 --> 00:09:46.215 I do plan to eventually get like proper some sort of Oauth
00:09:46.215 --> 00:09:49.547 commands to like have you guys generate your own personal
00:09:49.547 --> 00:09:52.820 access tokens on your own machines that so we don't have
00:09:52.820 --> 00:09:53.797 to hardcode that.
00:09:54.027 --> 00:09:57.149 But for the moment, that should be pretty safe to have in there,
00:09:57.149 --> 00:09:58.927 since it's again really and skilled.
00:10:02.497 --> 00:10:02.657 Right.
00:10:03.007 --> 00:10:06.507 So and we can update including to a particular version.
00:10:07.957 --> 00:10:11.500 So really all that's happening in here is just these two
00:10:11.500 --> 00:10:15.603 builders as we want when we want to list them, we just, you know,
00:10:15.603 --> 00:10:19.457 give it our house repo, our auth token, repo name, et cetera.
00:10:21.677 --> 00:10:22.767 And then we want to update.
00:10:22.777 --> 00:10:23.727 We just tell it.
00:10:23.737 --> 00:10:24.067 What?
00:10:24.147 --> 00:10:25.327 What our current version is?
00:10:25.497 --> 00:10:29.876 Which cargo itself actually defines a macro that you can use
00:10:29.876 --> 00:10:34.184 to get the current version of your, like the program that's
00:10:34.184 --> 00:10:36.697 running, or other at compile time?
00:10:36.707 --> 00:10:40.920 I should say, you know, make it have some nice download progress
00:10:40.920 --> 00:10:42.087 bars and all that.
00:10:42.877 --> 00:10:45.387 Tell it which binary names to look for inside that package.
00:10:45.797 --> 00:10:48.506 So if we were to look back over here at the pipelines, which
00:10:48.506 --> 00:10:51.082 First off is just how that's going, looks like it's still
00:10:51.082 --> 00:10:51.437 running.
00:10:52.647 --> 00:10:54.027 So if you look over here.
00:11:00.577 --> 00:11:01.107 Reasons.
00:11:01.947 --> 00:11:06.372 So if I were to just download this guy and take a quick look
00:11:06.372 --> 00:11:06.807 at it.
00:11:12.807 --> 00:11:15.037 I'll probably be back so you can see here.
00:11:15.097 --> 00:11:18.257 It's really just contains one file just named Mystro 5.
00:11:19.087 --> 00:11:22.322 So this is telling it which path inside the binary to look for
00:11:22.322 --> 00:11:24.427 and to replace our current binary width.
00:11:27.777 --> 00:11:31.968 So then just in the main update command, we can optionally pass
00:11:31.968 --> 00:11:34.457 it in which version we want to go to.
00:11:36.287 --> 00:11:39.287 There's probably be some updates in here relatively soon.
00:11:39.557 --> 00:11:42.441 I'm going to probably do some updates to how it selects
00:11:42.441 --> 00:11:45.376 versions, because I think right now it'll just like even
00:11:45.376 --> 00:11:46.767 consider release Ken hates.
00:11:46.777 --> 00:11:50.930 Normally I would probably want to make that an explicit update
00:11:50.930 --> 00:11:52.447 to a release candidate.
00:11:52.457 --> 00:11:56.574 If you want to use that rather than uh or so, implicit outfits
00:11:56.574 --> 00:11:58.927 are only ever to official versions.
00:12:01.347 --> 00:12:01.817 Yeah.
00:12:01.857 --> 00:12:04.895 Then it just takes that tells it whatever target version we want
00:12:04.895 --> 00:12:05.737 and just tells it.
00:12:05.747 --> 00:12:11.001 Update now a cool little thing with rust here that would not
00:12:11.001 --> 00:12:13.327 have been quite so easy in.
00:12:14.837 --> 00:12:15.147 Net.
00:12:16.397 --> 00:12:20.095 So there's actually a bug in the current version of Self update
00:12:20.095 --> 00:12:23.157 where it does not properly pass the token to GitLab.
00:12:23.967 --> 00:12:27.177 So I was able to fork it just like my own.
00:12:27.187 --> 00:12:29.027 GitHub repository and then Justin cover.
00:12:29.067 --> 00:12:32.563 Them well, I can just tell it to go out to my GitHub repository
00:12:32.563 --> 00:12:35.567 and that's the self help the dependency 8-9 packets of
00:12:35.567 --> 00:12:37.807 publish a package or anything like that.
00:12:37.817 --> 00:12:38.497 It just goes.
00:12:39.607 --> 00:12:41.549 I'm going to see if I can get that committed back upstream
00:12:41.549 --> 00:12:41.747 later.
00:12:44.677 --> 00:12:44.967 Pass.
00:12:44.977 --> 00:12:45.527 Yeah.
00:12:45.907 --> 00:12:46.997 And they're just updates it.
00:12:47.227 --> 00:12:48.927 So just replaces his own binary.
00:12:49.557 --> 00:12:51.177 Nothing really complicated there.
00:12:52.877 --> 00:12:56.147 Ohh and there you see, the CIC process has finished.
00:12:57.427 --> 00:12:58.427 Actually, that's the way.
00:12:58.437 --> 00:13:05.360 Download so then in Maestro we can just do Maestro 5 uh version
00:13:05.360 --> 00:13:07.957 was the French versions.
00:13:08.477 --> 00:13:09.237 They have new one.
00:13:09.407 --> 00:13:13.422 You can updates actually just show you guys current version is
00:13:13.422 --> 00:13:13.677 R20.
00:13:15.487 --> 00:13:18.087 Yes, the one update, our version 21.
00:13:22.577 --> 00:13:25.897 Yeah, that's really the entire CCD process in there.
00:13:26.897 --> 00:13:30.488 Like we just build it and my guitar ball upload the tarball
00:13:30.488 --> 00:13:33.839 and then this thing just has logic to look for them and
00:13:33.839 --> 00:13:34.677 download them.
00:13:38.397 --> 00:13:38.737 Very cool.
00:13:40.207 --> 00:13:41.187 Any questions on that?
00:13:41.197 --> 00:13:43.147 Otherwise we can move over to Docker.
00:13:47.457 --> 00:13:48.547 From the one then the two.
00:13:51.207 --> 00:13:52.077 Yeah, you'll understand it.
00:13:52.087 --> 00:13:53.287 You will be implementing it tomorrow.
00:00:05.291 --> 00:00:05.451 Yep.
00:00:06.731 --> 00:00:06.951 Yeah, yeah.
00:00:07.701 --> 00:00:14.001 So basic overview and let me see if I can find some visual aids.
00:00:16.461 --> 00:00:16.801 Let's see.
00:00:18.701 --> 00:00:20.511 So basically.
00:00:23.281 --> 00:00:23.581 Here.
00:00:23.591 --> 00:00:24.071 That's.
00:00:24.441 --> 00:00:25.411 Yeah, they'll be some tough one.
00:00:26.321 --> 00:00:30.611 OK, so basically the difference between First off, just Docker
00:00:30.611 --> 00:00:34.970 versus VM, a virtual machine is truly emulating the entire Dara
00:00:34.970 --> 00:00:39.396 machine as far as what's running inside the VM is concerned like
00:00:39.396 --> 00:00:40.621 it is the machine.
00:00:41.661 --> 00:00:45.599 Uh Docker containers or just plain containerization in
00:00:45.599 --> 00:00:46.171 general?
00:00:46.181 --> 00:00:48.441 Because there's more to containerization than just
00:00:48.441 --> 00:00:48.751 Docker.
00:00:51.041 --> 00:00:54.503 Basically it uses features within the operating system
00:00:54.503 --> 00:00:58.406 itself to essentially partition like the running space of the
00:00:58.406 --> 00:01:02.119 operating system so that I process running in one space is
00:01:02.119 --> 00:01:06.148 not able to see anything that is not explicitly given access to
00:01:06.148 --> 00:01:09.861 as well as not able to see anything outside its own space.
00:01:12.041 --> 00:01:15.463 So like you could see a minute ago when turning each shop, I
00:01:15.463 --> 00:01:18.997 was able to see the processes running inside CI CD because I'm
00:01:18.997 --> 00:01:20.791 like I'm in the outer container.
00:01:21.161 --> 00:01:24.216 If I were inside that container, I wouldn't be able to see
00:01:24.216 --> 00:01:27.271 anything right on the main system, so it's much, much more
00:01:27.271 --> 00:01:30.171 lightweight than a full VM because obviously it doesn't
00:01:30.171 --> 00:01:33.536 have to go through all the work of like emulating a processor or
00:01:33.536 --> 00:01:36.643 doing whatever other weirdness that entails running its own
00:01:36.643 --> 00:01:38.921 version of the operating system, et cetera.
00:01:41.991 --> 00:01:44.348 Really, the lockerdome doesn't actually come to play in this
00:01:44.348 --> 00:01:44.541 part.
00:01:45.481 --> 00:01:49.950 That's really just orchestrating which what they would be called
00:01:49.950 --> 00:01:52.631 as process name spaces are being used.
00:01:54.061 --> 00:01:57.227 So technically this thing should really look like this directly
00:01:57.227 --> 00:01:58.611 onto those operating system.
00:01:58.651 --> 00:02:00.651 This directory and host operating system and so on.
00:02:03.141 --> 00:02:05.521 Uh, so benefits?
00:02:05.531 --> 00:02:08.803 There are pretty obvious like you don't have to have multiple
00:02:08.803 --> 00:02:11.705 different host operating systems, although you do have
00:02:11.705 --> 00:02:14.818 obviously different copies of files in each container, you
00:02:14.818 --> 00:02:17.878 don't need to emulate the processor just runs directly on
00:02:17.878 --> 00:02:20.621 there, so the performance is basically just native.
00:02:21.701 --> 00:02:25.401 Uh, now that does bring some issues with security, at least
00:02:25.401 --> 00:02:29.348 theoretically, since obviously if you can find a kernel exploit
00:02:29.348 --> 00:02:33.048 in the host operating system, you can theoretically go from
00:02:33.048 --> 00:02:36.131 that little name space over to another namespace.
00:02:37.101 --> 00:02:40.442 There is some stuff nowadays to work around that, but I won't
00:02:40.442 --> 00:02:41.681 try to cover that here.
00:02:44.391 --> 00:02:48.133 So that's the basic way like basic difference between virtual
00:02:48.133 --> 00:02:49.521 machine that container.
00:02:49.591 --> 00:02:51.581 Any questions on just the theoretical stuff?
00:02:57.071 --> 00:02:57.591 Makes sense to me.
00:02:57.481 --> 00:02:57.671 Correct.
00:02:58.571 --> 00:02:59.491 National Ramble on.
00:03:01.461 --> 00:03:04.751 OK, so Docker is one such containerization thing.
00:03:04.761 --> 00:03:06.963 There's also other stuff like for example, you might seem to
00:03:06.963 --> 00:03:07.721 use podman sometimes.
00:03:08.511 --> 00:03:08.961 Umm.
00:03:10.641 --> 00:03:10.911 Oops.
00:03:12.171 --> 00:03:12.451 SQL.
00:03:13.601 --> 00:03:14.741 Uh, really?
00:03:14.751 --> 00:03:16.451 They're all using the same thing on the next.
00:03:17.261 --> 00:03:21.288 It's just how they work internally, or rather how they
00:03:21.288 --> 00:03:23.191 orchestrate the container.
00:03:23.201 --> 00:03:27.746 Slash namespaces is different, so we'll probably just focus on
00:03:27.746 --> 00:03:28.251 Docker.
00:03:28.501 --> 00:03:31.591 Podman basically works exactly the same, and in fact podman
00:03:31.591 --> 00:03:34.423 even has a way that like has compatibility with Docker
00:03:34.423 --> 00:03:35.041 commands so.
00:03:39.941 --> 00:03:43.979 So first foundational thing, there are images and are
00:03:43.979 --> 00:03:44.801 containers.
00:03:45.641 --> 00:03:49.601 So an image is the and hit me.
00:03:51.741 --> 00:03:56.291 Open up the concept project so an image is the actual like
00:03:56.291 --> 00:04:01.148 tarball of all of the files that are supposed to be inside the
00:04:01.148 --> 00:04:02.921 container when it runs.
00:04:05.111 --> 00:04:06.751 I wonder is there a way I can?
00:04:11.891 --> 00:04:13.241 Just export the.
00:04:13.301 --> 00:04:14.581 Yes, sweet.
00:04:22.721 --> 00:04:27.171 OK, so if I just do a quick car Expo or TTC?
00:04:29.581 --> 00:04:30.861 Oops, actually gzipped.
00:04:33.081 --> 00:04:33.381 OK.
00:04:34.671 --> 00:04:37.880 I guess there's a little bit more to what it has, but
00:04:37.880 --> 00:04:41.682 basically that where there is an image so it looks like the the
00:04:41.682 --> 00:04:45.543 image that it gets exported here doesn't technically contain the
00:04:45.543 --> 00:04:48.751 actual files that go into the file system eventually.
00:04:50.641 --> 00:04:57.711 So if I were to real quick, just exactly oops is that.
00:04:59.871 --> 00:05:01.801 We should just look at what this thing does.
00:05:07.231 --> 00:05:12.951 So basically in Docker in particular, images are built as
00:05:12.951 --> 00:05:13.641 layers.
00:05:13.991 --> 00:05:17.539 So if you've ever looked at a Docker file for example, you can
00:05:17.539 --> 00:05:18.721 look at the one oops.
00:05:19.011 --> 00:05:20.251 Oops, I'm on the right folder.
00:05:22.281 --> 00:05:25.590 If you look at the Docker file for connect, we see the first
00:05:25.590 --> 00:05:28.845 thing is from and then this image path as whatever you want
00:05:28.845 --> 00:05:29.441 to call it.
00:05:29.811 --> 00:05:33.706 So this is reaching out, getting that existing image which itself
00:05:33.706 --> 00:05:37.542 may be built of other images and then using that as a base point
00:05:37.542 --> 00:05:41.259 so that any changes we make from there are recorded separately
00:05:41.259 --> 00:05:43.501 from what was in that original image.
00:05:44.071 --> 00:05:47.516 So images themselves that you can see are essentially
00:05:47.516 --> 00:05:48.281 incremental.
00:05:48.551 --> 00:05:50.941 You don't have to save the entire thing each time.
00:05:50.951 --> 00:05:53.091 You can just save what changed from its base image.
00:05:56.921 --> 00:06:01.321 So you can see here the Alpine image just uh, actually, I guess
00:06:01.321 --> 00:06:04.071 outlines probably even more base image.
00:06:04.081 --> 00:06:08.658 But so ultimately then, once you've merge all the layers, you
00:06:08.658 --> 00:06:13.161 just have a set of all the files that you need to work with.
00:06:14.381 --> 00:06:17.136 They can just be mounted as if they were even at the root
00:06:17.136 --> 00:06:17.611 directory.
00:06:18.021 --> 00:06:22.723 So if I were to do like a pod, men run, so this will be running
00:06:22.723 --> 00:06:25.441 the Alpine image as a new container.
00:06:25.571 --> 00:06:28.411 So containers are running instances of images.
00:06:30.331 --> 00:06:32.971 Looking to see how my roots like I can look inside my home
00:06:32.971 --> 00:06:34.671 directory and you don't see anything.
00:06:35.751 --> 00:06:39.939 If I look at outside, obviously I can see what's on my wheel
00:06:39.939 --> 00:06:40.351 drive.
00:06:46.781 --> 00:06:50.721 One thing to note, as just as a side thing, you should never
00:06:50.721 --> 00:06:54.079 really have mutable state directly inside the image
00:06:54.079 --> 00:06:54.531 itself.
00:06:55.041 --> 00:06:56.251 You can for that.
00:06:56.261 --> 00:06:58.911 You can mount different volumes.
00:06:58.961 --> 00:07:03.765 So, like, let's say I want to melt the volume, maybe just the
00:07:03.765 --> 00:07:05.391 current directory at.
00:07:08.071 --> 00:07:10.402 Maybe it's like a folder on the root called source or something
00:07:10.402 --> 00:07:10.911 that it's not.
00:07:10.921 --> 00:07:14.839 If I look inside source you can see that's the directory I just
00:07:14.839 --> 00:07:18.451 came from, so it's just melted transparently inside there.
00:07:21.221 --> 00:07:25.641 So if I were to, there's something there.
00:07:27.281 --> 00:07:29.941 X and back out you can see through us here.
00:07:36.791 --> 00:07:37.131 Let's see.
00:07:38.721 --> 00:07:41.739 Think of anything else we should be the go over, like
00:07:41.739 --> 00:07:42.521 theoretically.
00:07:45.001 --> 00:07:47.471 So namespaces extend to a lot of things.
00:07:47.761 --> 00:07:51.855 Obviously extends to the file system, so like which files
00:07:51.855 --> 00:07:55.877 you're able to see, just as a even more base thing for a
00:07:55.877 --> 00:07:56.371 moment.
00:07:57.381 --> 00:08:01.242 Uh, Linux, and really just unixes in general don't really
00:08:01.242 --> 00:08:05.436 have the concept of different drives per SE, the same way that
00:08:05.436 --> 00:08:08.631 Windows has, like drive letters, CDE, whatever.
00:08:09.721 --> 00:08:14.121 Umm he has devices which are actually themselves files.
00:08:14.271 --> 00:08:18.447 So for example, my hard disk here is andme 0 and then there
00:08:18.447 --> 00:08:22.691 are different partitions that are all just exposed as files.
00:08:24.011 --> 00:08:26.831 So whenever they get mounted, they just become new folders.
00:08:28.801 --> 00:08:32.521 So like if I were to look at amount real quick.
00:08:35.161 --> 00:08:38.471 A good example here that was a better example.
00:08:41.821 --> 00:08:43.671 Here so like my NBME.
00:08:44.851 --> 00:08:48.311 So first Dr #1 partition one.
00:08:48.721 --> 00:08:51.774 That's just my boot boot partition that contains the boot
00:08:51.774 --> 00:08:55.142 loader and all that, so that's actually mounted as just another
00:08:55.142 --> 00:08:57.141 folder, so I can just see that there.
00:09:00.291 --> 00:09:02.661 So that same thing is what gets used in name spaces.
00:09:02.671 --> 00:09:06.573 So really it's just mounting existing stuff into particular
00:09:06.573 --> 00:09:10.410 places inside the namespace, so the root becomes something
00:09:10.410 --> 00:09:14.376 different than what was in the host operating system, and so
00:09:14.376 --> 00:09:14.571 on.
00:09:16.841 --> 00:09:18.911 And the extends like I'm saying to even more stuff.
00:09:18.921 --> 00:09:24.247 So network for example, if you look here, I have actually on
00:09:24.247 --> 00:09:25.381 the down low.
00:09:25.671 --> 00:09:28.621 So here are all of my current network adapters.
00:09:29.191 --> 00:09:32.331 Not all of them physical, however.
00:09:32.341 --> 00:09:36.924 If I were to go into a container, you'll see I only
00:09:36.924 --> 00:09:39.391 have these two available so.
00:09:40.981 --> 00:09:45.527 Even network cards themselves are virtualized or I shouldn't
00:09:45.527 --> 00:09:49.401 say virtualized, exposed to containers selectively.
00:09:50.661 --> 00:09:54.282 So you can really control everything that each individual
00:09:54.282 --> 00:09:57.965 container has access to, and just to show a second earlier
00:09:57.965 --> 00:09:58.901 developed here.
00:09:59.331 --> 00:10:01.582 According to this container, these are the only two things
00:10:01.582 --> 00:10:02.421 existing in the world.
00:10:03.811 --> 00:10:05.161 I could also do limits.
00:10:05.291 --> 00:10:08.059 This container is only able to see a certain amount of memory a
00:10:08.059 --> 00:10:09.831 certain number of processors, et cetera.
00:10:14.161 --> 00:10:18.169 So then moving into Docker proper, here's the Docker file
00:10:18.169 --> 00:10:21.001 that I currently have going for connect.
00:10:21.151 --> 00:10:24.926 This will probably be something like what we have going once we
00:10:24.926 --> 00:10:27.934 get like full dockerized cicd going with automatic
00:10:27.934 --> 00:10:28.641 deployments.
00:10:30.051 --> 00:10:34.397 So we take the official Microsoft image for the SDK,
00:10:34.397 --> 00:10:39.562 some panel line just means that I'm building off of the Alpine
00:10:39.562 --> 00:10:44.810 like variant of that, just for reference, Alpine is like a puny
00:10:44.810 --> 00:10:47.351 little Linux distro so far ago.
00:10:47.721 --> 00:10:48.391 Look that up.
00:10:48.581 --> 00:10:50.921 I think it's like 30 megabytes or less.
00:10:57.461 --> 00:11:03.026 Where was the size there so the entire Alpine Linux system is
00:11:03.026 --> 00:11:04.461 less than eight?
00:11:04.531 --> 00:11:06.001 Yeah, less than 8 megabytes.
00:11:09.411 --> 00:11:14.036 So it's just puny easy to just download, install, have tons of
00:11:14.036 --> 00:11:15.871 them running all at once.
00:11:19.211 --> 00:11:20.381 As we said, our working directory.
00:11:20.391 --> 00:11:23.995 So basically we just say that the source directory is where
00:11:23.995 --> 00:11:27.598 we're going to do all of our subsequent commands, copy from
00:11:27.598 --> 00:11:31.321 the build context to the the current directory, which is that
00:11:31.321 --> 00:11:31.741 source.
00:11:32.131 --> 00:11:34.331 So Docker has the concept of a build context.
00:11:35.461 --> 00:11:39.231 So like if I were to run a Docker build here, that dot is
00:11:39.231 --> 00:11:40.401 the build context.
00:11:42.021 --> 00:11:44.521 So in other words, that's my local folder.
00:11:46.841 --> 00:11:49.689 Basically that means that only the files within the build
00:11:49.689 --> 00:11:51.751 context are available to the Docker file.
00:11:51.761 --> 00:11:54.361 To do anything, just cancel that through to wait for that.
00:11:55.651 --> 00:11:58.877 Just like in get, there is isolated Docker ignore that you
00:11:58.877 --> 00:12:02.211 can use to choose which files get sent to the build context.
00:12:04.081 --> 00:12:07.866 So basically, none of these file folders and files will ever be
00:12:07.866 --> 00:12:09.521 visible in Docker initially.
00:12:14.111 --> 00:12:15.081 Let's get over there again.
00:12:15.571 --> 00:12:20.313 So we copy our folders and files of the current thing from the
00:12:20.313 --> 00:12:24.151 build context over, make a new directory named at.
00:12:24.161 --> 00:12:25.101 That's we're gonna publish to.
00:12:25.111 --> 00:12:28.081 So then we just publish this thing.
00:12:28.091 --> 00:12:28.871 I'm cheating a little.
00:12:28.881 --> 00:12:29.861 I'm just a wild carding.
00:12:29.871 --> 00:12:33.128 I'm laying the shell figure out which client I'm doing so that
00:12:33.128 --> 00:12:36.281 way it's client agnostic in debug mode to the app directory.
00:12:37.651 --> 00:12:41.011 Then we introduce another separate image altogether.
00:12:41.561 --> 00:12:46.678 So from the ASP net image, which is what's required to actually
00:12:46.678 --> 00:12:51.635 run this thing in the end as our public image, we go go to or
00:12:51.635 --> 00:12:56.352 make a new App directory, copy from the build image to our
00:12:56.352 --> 00:12:58.111 current app directory.
00:12:59.581 --> 00:12:59.991 Uh.
00:13:01.141 --> 00:13:04.840 And then just once again, so we don't have to like care which
00:13:04.840 --> 00:13:06.271 client name it truly is.
00:13:06.971 --> 00:13:11.080 I use this as a little hack to just like have a DLL that's
00:13:11.080 --> 00:13:12.611 named something known.
00:13:12.921 --> 00:13:16.861 So the entry point down here can then just point to this like the
00:13:16.861 --> 00:13:20.622 Docker file doesn't have to be edited to say clients dot CS or
00:13:20.622 --> 00:13:22.711 clients at Winco or whatever else.
00:13:23.181 --> 00:13:23.951 It just knows.
00:13:23.961 --> 00:13:24.151 OK.
00:13:24.161 --> 00:13:27.883 I just go to this file and then this file just points to
00:13:27.883 --> 00:13:31.800 whatever we truly need and then we expose a particular port
00:13:31.800 --> 00:13:34.411 outside of there so that that was good.
00:13:34.421 --> 00:13:38.354 Just means that the Docker system is able to expose that
00:13:38.354 --> 00:13:40.561 port to whatever else is needed.
00:13:43.621 --> 00:13:48.821 Let's go and adaptability and real quick and you can see it.
00:13:48.931 --> 00:13:50.301 It's able to cache all the steps.
00:13:50.451 --> 00:13:51.761 It's like it doesn't have to recopy.
00:13:51.771 --> 00:13:54.341 It does have to make those directories again.
00:13:54.591 --> 00:13:57.280 It knows that nothing else changed in the build context
00:13:57.280 --> 00:14:00.353 since the last time around that, so it's just able to reuse all
00:14:00.353 --> 00:14:01.121 the other stuff.
00:14:01.591 --> 00:14:04.465 Sorry, there was able to just run the net publish and that's
00:14:04.465 --> 00:14:06.161 it because that's the only I think.
00:14:06.251 --> 00:14:10.221 This part where I had probably control seed from a little bits.
00:14:10.451 --> 00:14:11.151 Yeah, that's enough.
00:14:12.461 --> 00:14:13.781 So I just built this new image.
00:14:14.931 --> 00:14:17.911 Now I could actually run something inside there.
00:14:19.841 --> 00:14:21.721 I'll get into what those flags mean is the 2nd.
00:14:25.131 --> 00:14:28.761 Oops whoops, I need to override that.
00:14:29.961 --> 00:14:32.551 So you saw in there and entry point to find.
00:14:32.621 --> 00:14:33.651 So that's what it charged us.
00:14:33.661 --> 00:14:34.491 Run just now.
00:14:34.921 --> 00:14:37.491 I'm going to just for a second here, override that entry point.
00:14:37.541 --> 00:14:40.411 So instead of just normal shell so I can get inside there and
00:14:40.411 --> 00:14:42.401 look around without trying to run connect.
00:14:43.951 --> 00:14:46.111 So you can see here we have our published output of all that.
00:14:48.011 --> 00:14:52.877 Uh, so when it actually runs, it's basically just going to do
00:14:52.877 --> 00:14:54.211 net, Andrew Dull.
00:14:55.511 --> 00:14:59.458 Of course, I don't have apps and stuff mounted in there at the
00:14:59.458 --> 00:15:03.280 moment, which will may or may not get too into this session,
00:15:03.280 --> 00:15:06.161 so that's just not able to run at the moment.
00:15:08.181 --> 00:15:10.021 See if I have any other containers running of them.
00:15:10.031 --> 00:15:11.481 We can look at no darn.
00:15:14.111 --> 00:15:17.191 So real quick these flags I was using double dash ram means
00:15:17.191 --> 00:15:19.141 remove the container after it's done.
00:15:19.811 --> 00:15:24.911 So if I were to take this thing off, oops, we use the right one.
00:15:25.441 --> 00:15:26.911 Take this thing off on here.
00:15:26.921 --> 00:15:30.815 I can XML back out of here, so if I do a Docker PS which this
00:15:30.815 --> 00:15:34.771 means just like show all running containers, it shows nothing.
00:15:34.781 --> 00:15:38.139 If I do a PSA, so show all containers, whether they're
00:15:38.139 --> 00:15:41.864 running or not, it will still show the one that's exited the
00:15:41.864 --> 00:15:45.344 dash RN that I used before basically just means once the
00:15:45.344 --> 00:15:48.885 container has exited, or rather once it's entry point has
00:15:48.885 --> 00:15:51.021 exited, just delete the container.
00:15:51.031 --> 00:15:51.851 We don't care about it anymore.
00:15:56.621 --> 00:16:01.691 So I'm trying to think of a good way to show the other stuff.
00:16:09.001 --> 00:16:10.761 I have the watchtower thing.
00:16:14.111 --> 00:16:15.011 Yeah, here.
00:16:15.021 --> 00:16:16.021 This will be a good example.
00:16:16.941 --> 00:16:20.561 OK, so I just ran another container so now it has.
00:16:21.281 --> 00:16:23.911 Uh watchtower itself?
00:16:24.141 --> 00:16:26.990 It's an apple probably be using CCD won't go too much into what
00:16:26.990 --> 00:16:27.791 it does right now.
00:16:29.461 --> 00:16:31.531 We give it an it's container name.
00:16:31.901 --> 00:16:32.511 We mount.
00:16:32.621 --> 00:16:35.450 This actually allows us to mount the particular file directly
00:16:35.450 --> 00:16:35.951 into there.
00:16:36.621 --> 00:16:40.530 So in this case, that just means that Watchtower itself is able
00:16:40.530 --> 00:16:44.439 to access the like root Docker socket, communicate with it, and
00:16:44.439 --> 00:16:47.431 uh basically tell it to do whatever it needs to.
00:16:50.341 --> 00:16:51.731 So now we have these running ones.
00:16:51.741 --> 00:16:56.023 So from here the main commands that we would really be end up
00:16:56.023 --> 00:17:00.442 being are really really end up using exec so we can exec inside
00:17:00.442 --> 00:17:01.201 Watchtower.
00:17:01.211 --> 00:17:02.971 For example, people like finish.
00:17:04.061 --> 00:17:04.431 Oops.
00:17:05.131 --> 00:17:05.881 It doesn't even have.
00:17:07.431 --> 00:17:08.121 That's interesting.
00:17:08.751 --> 00:17:10.661 They may have turned that thing down a fair bit.
00:17:15.411 --> 00:17:16.291 That's a bad example.
00:17:19.161 --> 00:17:19.951 Here one second.
00:17:20.441 --> 00:17:21.421 What I can do?
00:17:25.181 --> 00:17:27.901 I'm going to restart the CI CD process.
00:17:34.211 --> 00:17:34.661 The.
00:17:39.111 --> 00:17:40.511 Standard tiny UI.
00:17:46.491 --> 00:17:47.381 Where is the job.
00:17:49.821 --> 00:17:51.381 Alright, OK.
00:17:51.391 --> 00:17:57.351 So if I do a Docker PSA there, I think that's the prebuild.
00:17:57.361 --> 00:18:00.112 So we have to wait a second or two for the the main build
00:18:00.112 --> 00:18:00.491 startup.
00:18:01.161 --> 00:18:06.294 It's now if we move fast, we can expect the IT there basically
00:18:06.294 --> 00:18:11.181 means interactive and like cannot remember what that means.
00:18:12.121 --> 00:18:13.511 Actually it's there.
00:18:13.521 --> 00:18:15.701 I just ran benezech inside that container.
00:18:16.031 --> 00:18:19.451 So during the CCD process, I can actually just like go.
00:18:27.461 --> 00:18:31.106 So I can see things happening and all that, so I can look
00:18:31.106 --> 00:18:32.551 inside the cargo. Toml.
00:18:32.861 --> 00:18:35.712 We can see that it did in fact already run the side commands to
00:18:35.712 --> 00:18:36.291 replace that.
00:18:36.391 --> 00:18:36.851 Etcetera.
00:18:37.261 --> 00:18:41.211 So Docker exec allows you to run a command inside of an already
00:18:41.211 --> 00:18:42.321 running container.
00:18:44.991 --> 00:18:49.031 Next useful one is probably Docker logs, so I could run logs
00:18:49.031 --> 00:18:49.891 against that.
00:18:49.901 --> 00:18:52.651 I could see what's doing the dash F option on.
00:18:52.661 --> 00:18:56.443 That means follow, so it will follow the log and just as new
00:18:56.443 --> 00:18:59.790 stuff comes which this might take a few seconds to do
00:18:59.790 --> 00:19:03.261 something, it will just continuously update our screen.
00:19:05.111 --> 00:19:06.131 They give a few seconds here.
00:19:09.801 --> 00:19:12.960 Of course I had to get to this part of things when it was on
00:19:12.960 --> 00:19:14.461 the thing that takes forever.
00:19:19.371 --> 00:19:22.243 So this Docker have like its own language then and the Docker
00:19:22.243 --> 00:19:24.141 file is a scripting language of its own.
00:19:23.971 --> 00:19:24.271 And then.
00:19:24.151 --> 00:19:25.211 Or is it a specific language?
00:19:28.311 --> 00:19:30.921 It's it's own scripting language per se.
00:19:32.641 --> 00:19:35.401 I'm sorry up there.
00:19:35.661 --> 00:19:38.261 So you can see it's following blogs as they get output.
00:19:39.691 --> 00:19:44.072 So technically, yes, this is its own language in that like the
00:19:44.072 --> 00:19:45.741 from and all that stuff.
00:19:45.751 --> 00:19:47.341 That's all Docker specified.
00:19:47.751 --> 00:19:52.524 Or technically speaking, it's it is a standard nowadays I believe
00:19:52.524 --> 00:19:52.741 so.
00:19:54.371 --> 00:19:58.413 Like obviously pop band or technically it's builder Nate,
00:19:58.413 --> 00:20:02.803 which is named buildup is able to use the same spec but inside
00:20:02.803 --> 00:20:03.221 there.
00:20:03.231 --> 00:20:07.434 So like when I'm doing a run right here, this is invoking the
00:20:07.434 --> 00:20:11.771 current shell for that container or I should say for that image
00:20:11.771 --> 00:20:13.601 and it's just running that.
00:20:13.611 --> 00:20:16.751 So if we were to somehow set the shell correct.
00:20:14.591 --> 00:20:15.541 So those are Linux commands.
00:20:16.761 --> 00:20:20.756 So if I was well, to be precise, it's stuff that will work
00:20:20.756 --> 00:20:24.141 running under the shell, which here would be ash.
00:20:25.681 --> 00:20:28.591 So if we were to somehow like set the shell to maybe Python.
00:20:28.881 --> 00:20:32.299 We could actually, I think just say run and then give it some
00:20:32.299 --> 00:20:35.551 arbitrary string of Python And it would just run it right?
00:20:33.291 --> 00:20:35.691 Ohh no.
00:20:35.811 --> 00:20:37.181 There's nothing special about a show.
00:20:37.191 --> 00:20:38.831 It's just take an input and given output.
00:20:39.391 --> 00:20:39.551 Yep.
00:20:41.531 --> 00:20:46.039 So yes, it is domain specific in most of its stuff, but then when
00:20:46.039 --> 00:20:49.863 it gets to run commands, it's just passing arguments to
00:20:49.863 --> 00:20:50.341 shells.
00:20:51.261 --> 00:20:51.561 Got it.
00:20:53.741 --> 00:20:57.381 Oops, guess that was doctor logs commands.
00:20:57.391 --> 00:20:58.741 You've already seen PSA.
00:21:00.321 --> 00:21:02.411 Uh, yeah.
00:21:02.421 --> 00:21:03.321 Why was there a failure?
00:21:04.061 --> 00:21:05.031 All the pipeline failed somehow.
00:21:07.641 --> 00:21:09.874 I'm guessing it's because I tried to rewrite it after I
00:21:09.874 --> 00:21:10.471 already worked.
00:21:12.611 --> 00:21:14.361 Anyway, I'll fix that later.
00:21:17.291 --> 00:21:17.651 Let's see.
00:21:19.261 --> 00:21:23.521 Just some other obvious commands or put things pretty obvious.
00:21:23.531 --> 00:21:27.165 What they do, you know, restart RM removes the container,
00:21:27.165 --> 00:21:28.981 etcetera, etcetera, etcetera.
00:21:29.911 --> 00:21:32.871 Uh, somewhat useful is Docker inspect.
00:21:35.351 --> 00:21:38.280 So that just basically just gives us a full description of
00:21:38.280 --> 00:21:39.421 what that container is.
00:21:40.421 --> 00:21:41.451 Uh, do notes.
00:21:41.821 --> 00:21:46.012 It is pretty common to pass secrets in environment variables
00:21:46.012 --> 00:21:47.591 in the container world.
00:21:48.071 --> 00:21:50.591 So if we were looking here, there might be some environment
00:21:50.591 --> 00:21:51.431 variables somewhere.
00:21:54.341 --> 00:21:55.251 Think.
00:21:55.641 --> 00:21:57.161 Yeah, there's one example.
00:21:58.981 --> 00:22:01.575 So do be careful with the output of Docker inspect because it
00:22:01.575 --> 00:22:03.081 could very well have secrets in it.
00:22:05.261 --> 00:22:07.710 And in this case, there aren't really any secrets for
00:22:07.710 --> 00:22:08.571 Watchtower to have.
00:22:08.581 --> 00:22:12.757 So and it also tells you like what networks are mounted and
00:22:12.757 --> 00:22:13.801 all that stuff.
00:22:17.631 --> 00:22:19.571 Next up, we'll probably be Doctor Prune.
00:22:20.891 --> 00:22:23.071 Oops, sorry, I think that's to give it.
00:22:26.011 --> 00:22:31.815 Well, other Docker image prune, so images, containers, etcetera
00:22:31.815 --> 00:22:34.081 have a pruned subcommand.
00:22:34.841 --> 00:22:37.268 Basically that means find any of them that are not currently
00:22:37.268 --> 00:22:38.421 running and just delete them.
00:22:41.851 --> 00:22:45.074 So in this case it probably just delete the one that I just ran a
00:22:45.074 --> 00:22:45.611 second ago.
00:22:46.951 --> 00:22:49.021 You also do with like image printer pruning.
00:22:49.491 --> 00:22:51.619 I'm not going to do that right now because I don't want it to
00:22:51.619 --> 00:22:53.506 redownload all the images I already have downloaded in
00:22:53.506 --> 00:22:53.711 cache.
00:22:55.851 --> 00:22:58.826 But that can be used sometimes to just like free up some hard
00:22:58.826 --> 00:22:59.641 hard drive space.
00:22:59.921 --> 00:23:03.470 They'll just prove any image that is not in use by a current
00:23:03.470 --> 00:23:04.051 container.
00:23:07.781 --> 00:23:08.121 Let's see.
00:23:09.891 --> 00:23:11.271 So they're useful ones.
00:23:17.171 --> 00:23:17.661 Commit.
00:23:17.811 --> 00:23:22.467 So theoretically you can make me mutations inside the container
00:23:22.467 --> 00:23:26.831 is file system and then you can commit them as a new image.
00:23:27.261 --> 00:23:29.111 That's actually basically what a Docker file is doing.
00:23:29.301 --> 00:23:31.251 It's just making changes and then committing them.
00:23:32.221 --> 00:23:36.150 Please do not do this with running systems to create new
00:23:36.150 --> 00:23:40.423 images, just it it just kind of defeats the purpose of Docker
00:23:40.423 --> 00:23:43.111 files and having that reproducibility.
00:23:45.541 --> 00:23:49.059 Like if you absolutely need to just to have it for later to
00:23:49.059 --> 00:23:52.811 debug or something, then yeah, but don't do it in order to make
00:23:52.811 --> 00:23:56.505 something that you you then like actually use as its own thing
00:23:56.505 --> 00:23:58.791 like here, use a Docker file for that.
00:24:01.441 --> 00:24:02.581 Uh, let's see.
00:24:04.051 --> 00:24:07.151 I think that's really the main stuff in there.
00:24:08.281 --> 00:24:11.531 There's also some other stuff that Docker itself exposes.
00:24:11.761 --> 00:24:15.780 For example, Docker Swarm, which is what we're currently looking
00:24:15.780 --> 00:24:18.191 at using for automatic client running.
00:24:18.201 --> 00:24:22.139 Essentially, that's not really like containers in general or
00:24:22.139 --> 00:24:23.301 Docker in general.
00:24:23.481 --> 00:24:27.664 That's something that Docker defines to allow running
00:24:27.664 --> 00:24:30.761 multiple containers as their own units.
00:24:31.171 --> 00:24:35.446 So like having connect and Postgres and you know whatever
00:24:35.446 --> 00:24:40.310 other images we need, like maybe a salad or something running all
00:24:40.310 --> 00:24:44.511 as separate containers but within like a little group in
00:24:44.511 --> 00:24:49.302 general images should only ever or rather containers should only
00:24:49.302 --> 00:24:53.871 ever have one process running or rather one main entry point.
00:24:53.931 --> 00:24:57.971 I guess one duty, you should say, uh, so swarm.
00:24:57.981 --> 00:24:58.411 Just thoughts.
00:24:58.421 --> 00:25:00.892 You have multiple different containers to have multiple
00:25:00.892 --> 00:25:02.701 different duties all being done at once.
00:25:07.011 --> 00:25:10.441 That's a bit similar, just off on the side thing for a second,
00:25:10.441 --> 00:25:12.401 but somewhere how Kubernetes works.
00:25:12.491 --> 00:25:15.567 If you've probably heard of that over there, they would call them
00:25:15.567 --> 00:25:18.316 pods and then each in each pod you have multiple different
00:25:18.316 --> 00:25:19.201 containers running.
00:25:20.611 --> 00:25:22.271 Obviously it gets more complicated about that.
00:25:25.291 --> 00:25:31.471 I don't think there's anything else useful when you make a or.
00:25:31.551 --> 00:25:34.467 Docker does have its own volume management like I can list the
00:25:34.467 --> 00:25:35.531 different volumes here.
00:25:36.971 --> 00:25:39.321 Uh, so you can have persistent information.
00:25:39.511 --> 00:25:42.303 It's not being stored in the image, it's being stored in its
00:25:42.303 --> 00:25:43.721 own completely separate volume.
00:25:43.931 --> 00:25:47.299 That's just being mounted into the image at runtime, so that
00:25:47.299 --> 00:25:50.502 does also mean that you can share a melted volume between
00:25:50.502 --> 00:25:51.661 different containers.
00:25:53.071 --> 00:25:55.481 Most common use for this would probably be for Postgres.
00:25:55.931 --> 00:25:59.103 You know you want to have a persistent volume that you use
00:25:59.103 --> 00:26:01.951 to store post, like the POSTGRES database inside of.
00:26:03.371 --> 00:26:07.052 Basically all you do is you mount the OR you mount the
00:26:07.052 --> 00:26:10.866 volume to the path where Postgres stores is database and
00:26:10.866 --> 00:26:15.016 Postgres is not to do anything different, it just keeps doing
00:26:15.016 --> 00:26:19.098 what it does and that path just so happens to be melted from
00:26:19.098 --> 00:26:20.101 somewhere else.
00:26:22.951 --> 00:26:23.211 Let's see.
00:26:25.631 --> 00:26:29.201 I think there's anything else normal useful for a dev.
00:26:33.451 --> 00:26:34.021 Obviously.
00:26:34.251 --> 00:26:37.702 So you remember in the dockerfile before it did expose
00:26:37.702 --> 00:26:41.591 8080, so that just means that we want to have that available.
00:26:41.821 --> 00:26:47.120 I don't think that implicitly exposes it to the host, so when
00:26:47.120 --> 00:26:52.589 you run a Docker, uh, container, that's actually a port I think
00:26:52.589 --> 00:26:57.374 was dash P yeah, so we can choose explicitly to publish
00:26:57.374 --> 00:27:01.561 some port from inside the container on the host.
00:27:01.791 --> 00:27:05.139 So basically what that means is we're just creating a bridge
00:27:05.139 --> 00:27:08.432 between our host port, maybe like port 80 to the containers
00:27:08.432 --> 00:27:08.871 port 80.
00:27:09.881 --> 00:27:11.211 And of course they can be asymmetric.
00:27:11.221 --> 00:27:15.523 So you could take your host port 8080 and have that be forwarded
00:27:15.523 --> 00:27:17.641 to port 21 inside the container.
00:27:17.651 --> 00:27:18.851 If you wanted to, doesn't really matter.
00:27:20.661 --> 00:27:24.120 01 other important thing to note, each container does have
00:27:24.120 --> 00:27:27.051 its own like I said before, its own network card.
00:27:27.061 --> 00:27:32.623 Essentially, it does have its own IP address as well, so if
00:27:32.623 --> 00:27:37.721 you look here, there's this Docker network device that
00:27:37.721 --> 00:27:39.111 Docker creates.
00:27:40.061 --> 00:27:41.451 You can see my current IP address.
00:27:41.461 --> 00:27:47.211 Inside there is the 172171721701 address.
00:27:48.131 --> 00:27:51.913 So each running container also has its own IP address, so we
00:27:51.913 --> 00:27:55.633 can look at this so we can actually just maybe inspect that
00:27:55.633 --> 00:27:55.881 one.
00:27:58.351 --> 00:28:01.885 Another time though, you can refer to things either through
00:28:01.885 --> 00:28:04.711 their tags, slash names, or through their hash.
00:28:05.501 --> 00:28:08.403 So in this case I can even just tab and like my shell has a
00:28:08.403 --> 00:28:11.111 bunch of completion, so it'll just know how to do that.
00:28:11.441 --> 00:28:15.221 I could also refer to it by the container ID, so we're looking
00:28:15.221 --> 00:28:15.521 here.
00:28:15.831 --> 00:28:21.755 We will see that it's own IP address inside the like Docker
00:28:21.755 --> 00:28:25.111 network is 1721702 uh by default.
00:28:25.121 --> 00:28:26.871 They are probably not able to talk to each other.
00:28:27.041 --> 00:28:30.502 It's like 2 containers that you have not explicitly allowed to
00:28:30.502 --> 00:28:34.018 talk to each other cannot send packets between each other, just
00:28:34.018 --> 00:28:35.391 obvious security reasons.
00:28:37.011 --> 00:28:39.875 When you create containers, you can create what's called a
00:28:39.875 --> 00:28:42.594 network and then you can basically just attach multiple
00:28:42.594 --> 00:28:45.701 containers to the same network and at that point they're all to
00:28:45.701 --> 00:28:46.671 route to each other.
00:28:47.271 --> 00:28:49.011 You can see each other by host name and so on.
00:28:52.601 --> 00:28:59.894 I see you remember, was there anything else you have to get
00:28:59.894 --> 00:29:00.501 into?
00:29:03.831 --> 00:29:08.841 But might really do it from the least the high level.
00:29:09.231 --> 00:29:11.761 Here's your crash course sort of perspective.
00:29:16.361 --> 00:29:16.641 Awesome.
00:29:18.681 --> 00:29:19.901 Any questions?
00:29:21.541 --> 00:29:23.861 I'm sure I skipped a lot and rambled a lot so.
00:29:31.301 --> 00:29:31.581 Good.
00:29:31.591 --> 00:29:32.911 Do you all be doing this tomorrow?