 and welcome to the fourth and final week of Understanding Containers. Taylor, do you notice anything different about your co-host? Yeah, you got new glasses this week. That's right, I did. Thank you very much for noticing. And I call them my George Romero glasses. Do you know who George Romero is? Yeah, yeah, famous film director. That's right, behind things like Night of the Living Dead, Dawn of the Dead, Creep Show, one of my all-time favorites. Anyway, when I say that, people are like, I don't really, I've never seen George Romero, so I don't know what you're talking about. So let me just do this for a second. Do you understand now? Are you gonna switch to a picture of him pretty soon? There it is. Oh, okay. Do you understand why I call them my George Romero glasses now? Yes, yeah. Thank you. Well, that's great. But that's not what we're here to talk about a week for. What we're here to talk about is actually, Taylor, you know, against my better judgment and against all I don't do it, he's gonna go on a tour, a speed tour of getting three applications up and running and reclaim cloud all on containers in less than 40 minutes. Do you think he can do it? I'm not so sure, but I'm gonna turn it over to the master himself and see what he can do. We're gonna try it out. We're gonna try it out. So just as a recap of where we're at, you probably have NextCloud running with HTTPS and such. If you want to keep your NextCloud instance around, feel free to do so. I don't need this one, so I'm gonna delete mine. But so my point is for this session, we're not gonna be doing anything with NextCloud. I actually have another instance of NextCloud that I'm already using. So I don't need mine, so I'm gonna delete it just so I have a fresh demo environment. We are going to get three applications running today. One of them is called HedgeDoc. One of them is called Basero and one of them is called WBO. And through that, we're gonna talk about tags in Docker, pulling updates, bind mounts, which we've talked about but haven't used, looking at logs and how we do that, and the concept of a Docker file, which is honestly pretty, all of these things are pretty, I would say more advanced stuff for running things in Docker. So, but I think the best part is we're just gonna run a couple of things. You can kind of see that process start to finish of like, hey, I found a new application. I see it mentions it supports Docker. How do I run it in Docker? I'm gonna throw it again over to the Glossary. Glossary, we need a Glossary cam. Yeah, the Glossary may well be in its final form now. And I have added, because I have added a page on the Docker file, which we'll get to, and images and tags, which we'll get to pretty soon. So we'll return to that, but the Docker file, sorry, the Glossary is here and it's got new stuff for you. So the first thing I'm gonna do to get three, just to save time in this video, because I'm only got 40 minutes, I'm going to make actually three different environments here. You, I would recommend separating this out if you're gonna follow along and try these three applications. I would recommend doing it in three environments just so you're sure that you have a clean space, basically, but I'll just say technically you could run one of these applications, delete the folder or file that you are working in and start over and keep using the same environment if you want it to. I think it's simpler to just make a new one though, personally, especially because then you can give it like a nice environment name. So I'm going to, for purposes of speed, I'm gonna make all three of these at once and I'm going to give them kind of standard names here. So we're gonna let that do its thing and I'm gonna go and make another one right away. I'm glad you're feeling the press of time. Yes, you know. I'm glad that we set that up right away. TikTok, should I do it here? TikTok, not the application, not that TikTok. Not that TikTok. The real original TikTok, the talk, the clock of the talk of the clock. So, yeah, one thing that is kind of cool and I'll have to take us out of the picture for a second. But if you probably haven't needed much need for this before in Reckling Cloud, but if you do what I just did for some reason, you can queue up multiple tasks like this and then you can go look at the progress of them as they run right from this screen by clicking this little triangle. So that's just like a handy thing that I like to point out. Oh, oh, hey George. That guy's stealing some screen time from me. Yeah, you know. He's truly a zombie, he's back from the dead. Okay, so while this is going, we're gonna go look at HedgeDoc first. So I've got something bookmarked. Like I said, HedgeDoc is the first application we're gonna run. It's basically Google Docs for Markdown files. So it lets you write Markdown files collaboratively online and it's really nice because you can share them publicly from there too, so you can make like a link and send it to somebody. It's a really nice little application. It's kind of like Etherpad, but for Markdown. So you can actually have formatting that you write in Markdown syntax. So anyway, in HedgeDoc's installation guide, they have a couple of official installation methods and the first one is Docker, so that's really cool. They have some, hey, you need these requirements, you need Docker Compose, you need Git, you need Docker 17.03. We have 19 already on our thing. You'll notice here that the official Docker images that says are available on quay.io. If I click on that, this is actually a container registry. It's like Docker Hub, but it's not Docker Hub. So this is one of the times that we're gonna pull a container not from Docker Hub, which is kind of interesting. And then below this, they have a basic Docker Compose file that we can get started with and you'll notice in here, it's actually got a separate database. So it's using Postgres for the database, which I'm not super familiar with. And then it has the username and password set up there. I'm gonna wanna change that, that's not a secure password. It sets volume up for the database, that's cool. It's going to have the, it's using quay.io for its image. You can see here that that's where, that's how in Docker Compose you tell it not to look in Docker Hub. And it's running using a couple environment variables. We've talked about this, but haven't used it a lot. And these are basically configuration changes that you can pass to HedgeDoc right from this file, which is super cool. It's using a volume for its uploads, which is like, I think where it's putting its images that you upload there. It's defining a port here, we're gonna wanna change that to 80. Yeah, and I noted before that we're gonna wanna change this password here because that's really insecure. But you'll also note, and this is kind of a tricky one, that that password also shows up here in the database URL thing. So we'll need to change, whatever we change this to here, we gotta put the same thing here. Otherwise, HedgeDoc won't be able to connect to the. Yeah, that's a detail that when you did this, you wouldn't realize unless someone pointed it out. So thank you. Yeah, and they kind of get around this by saying, and this is very common with Dr. Compose stuff, is they'll say, here's a sample for production environment, you'll wanna change it. But they don't really tell you what you'll wanna change. A lot of times, the first thing you wanna look at when people use that kind of language is passwords. How do I make sure my password is secure? They might be talking about other things too, like in terms of, sometimes when they use the word production, they're thinking of like a company selling access to HedgeDoc as a service. So that's very different than an individual in terms of traffic. We don't need to worry about that. But yeah, we do need to worry about the password here. So, and the other thing I wanna mention here is, it's going to meant, I brought up the fact that there's environment variables for configuring. And if I go to the configuration page in this here, HedgeDoc has an amazing table of all of the options that you can pass to it. And where they are, what they look like. So you can change things in the config file, which I'd honestly, I haven't looked enough at HedgeDoc to tell you where that file exists, but I'm sure we can find it. Or you can change it in the environment URL or environment variable, and it gives you that here. So these environment variables, that's where we know what can go in this section here, environment. And we can use these to do all kinds of things. You can set the URL that it's running on. I already run a HedgeDoc instance for something else. And I've set things in there that allow you to use a free URL, which is kind of like etherpad, where you can basically just make up a URL, visit it, and that's now a document. So that's an example of a setting. We'll play with that a little bit. So to get started here, we're going to copy this compose file. And I'm gonna go in my HedgeDoc environment that I just made, and they're all sitting here waiting for me. And I'm actually gonna need to go into the config area. And so I'll go in the root folder, which is the home folder of the user that we're running as, but technically this could be anywhere. It's just handy to organize it this way, I think. I'm gonna make a new folder. I'm gonna call it HedgeDoc, just so I have a place to work from. And I'm going to make a new file, call it docker-compose.yml, open it. And I'm gonna paste in their example. So the first thing I mentioned is that we're gonna wanna change that password. I'm going to just make up a password, turtles, tumble, tenaciously. There we go. That's good enough for now. I'm gonna copy that and also put it in this other spot where it wants the password. Great. Can I ask you about that password? Does it have any significance for you? I always, when I make up passwords, I like to do alliterations when they're not... I'll say my bank password, little more complicated than that. Okay, good. But I like alliteration passwords, so I usually like to use that. Turtles, tumble, tenaciously. Otherwise, if I was to tell you, hey, make up a password using three words, if you don't give yourself a limit, it's hard to do that, right? You're like, I don't know, what three words? So limiting myself to an alliteration helps to create a process. It reminds me of the Teenage Mutant Turtles. There's a little bit of that going on. Yeah, for sure. That's where Turtles comes from because I'm playing the new Teenage Mutant Ninja Turtles game right now. Not right now. That would be an amazing feat of multitasking. No, hopefully not. Yeah, so, yes. So it says command domain. We probably need to change this for our environment to work long-term. Basically, if you're gonna map a domain, you put this there. I can tell you from experience that it's going to affect the links it makes when you click on them. We're just gonna leave this for right now. I wanna do the bare minimum to get this working. And we're gonna put port 80 in instead of port 3000 just to make sure we can load it properly. Yeah, so let's try that out. One more thing I'm going to demonstrate here. I'm actually gonna pull an old version of this application. So this gets a new concept for us, and this is called a tag. You can see here it says the image we're pulling for HedgeDoc is quay.io-hedge-doc-hedge-doc colon 1.9.3. This is what's called a doctor tag, and it's essentially just a version, basically. So if I go over to our glossary, one thing I realize I never actually defined of been throwing this word around is an image. So we run a container, right? That's a Docker container. An image is just essentially what gets uploaded to a registry to allow your server to make to run a container. So it's basically just the name for that. I kind of, there's a lot more technical complexity to it than that, most of which I don't understand. But you can kind of think of it like meteor versus meteorite. It's like, for our purposes, it's the same thing, but once it enters the reclaimed cloud atmosphere, it's called a container now. So containers, basically, when you're running a container, it's built from an image that you run from the registry. So yeah, and then tags are a way for Docker to keep track of images and basically versions. So if you don't specify a tag and again, the tag is this colon and whatever comes after the colon in the image section here, it will pull the latest version every single time you pull the image. This is good. It can be, honestly, a lot of times it's what you want, but it can be dangerous. Like if you're not comfortable with your application automatically updating all the time or every time you pull updates via Docker, you might not want that. In their particular example for HedgeDoc, they're specifying manually that it was 1.9.4. I'm gonna take advantage of this fact to actually pull an old version just so we can show how updates work in Docker because we really haven't updated anything yet. So I'm gonna tell it to do 1.9.3. Hopefully that's fine. So now that I've got that file set up, I'm gonna go into our terminal and go into the HedgeDoc folder that I made and I'm gonna run my Docker compose up dash D and it's pulling in some containers. That's cool, or it's pulling images, sorry. You can see here it's using 1.9.3. The interesting thing about tags is that tags aren't always numbers. You can, developers can give tags to all kinds of images. Sometimes you'll on Docker Hub, you'll see the tags available for a container are specific version numbers like this, but also things like beta and stable. And that will say, oh, this tag will always apply to images that are on our testing area. So they're tagged with beta. So basically my point being, you do have to look at the documentation to see what the tags the developer has to find are because they aren't always going to be numbers. They can be whatever they want. They could theoretically name them like we name hurricanes every single time they do a release. That's, you know, just give it a first name, that tags or whatever developer puts in there. So that's running and let's see if it's working. Okay, so I clicked on the URL here and it looks like it's kind of working, it's kind of busted because I'm guessing there's, I need to probably fill in that domain field in our Docker compose file. So I'll do that in a second, but we're also gonna try updating here too. So the first thing I'm gonna do is go back to my compose file, which I still have open over here. So I'm gonna change this to 1.9.4 and I'm also gonna go and set the command, the domain field. And I'm just gonna copy the Recklin Cloud one, get rid of the slashes and HTTP around it. Let's try that. Okay, so two things we did there, right? We changed an environment variable and we changed the tag. So first thing we need to do to make our changes happen is take the whole stack down and we're going to pull an update. Now this is in the Glassery, this command, but we're gonna do a Docker compose pull. And that's just going to go and check that it has the correct image for the container. So you'll notice that it basically looked at database and said, I'm done. And then it did some work on app. And that's because in our compose file, the app section is what we just changed here for the HedgeDoc. I should note too that these services, you have to give them names in the compose file. And these are really just for human readability. I could give these whatever name I wanted to. So it is nice, I think, to define it that way, but just note that if you're running in something in Docker compose that you're writing yourself, you can name those whatever you want. Okay, so we pulled an update and let's do an up and it's not loading yet. Uh-oh, oh, it's because I'm trying to load it over HTTPS. There we go. Still not working with, there's no style coming in for some reason. Let me look at that really quick. Hedge settings. I see, it's because it's trying to pull in a bunch of resources over HTTP, of course, because we haven't set up HTTPS yet, but there must be some setting in HedgeDoc that says, hey, you have to load over HTTP. So I could look at HedgeDoc settings and see exactly what's going on there or I could actually just turn on our built-in SSL in Reclaim Cloud. For the purposes of moving on, I'm going to, for this video, I'm gonna actually move on at this point because we do have the application running and working, but we would have to configure it yet, again, with these variables here. So we would need to get HTTPS working. I think what I'm gonna do is I'm gonna throw a load balancer in front of this, just like we did before with our next cloud and I'm going to return to this later so we can keep moving on, but that's one example of a Docker compose file and how we can pull updates. So can I ask you something while you move on? If you just did the shared load balancer SSL certificate, would that not be enough? It probably would be, but I would have to have turned off the IP address. Yeah, that also would have been another path here, but basically I'm just doing it this way because it's more similar to how we did the next cloud. It's a good example, though, for me, and I'll let you go on to your next one because I know we have you on a time limit of how many of some of the issues you'll run into with any of these apps will be SSL related. Totally. Like it is a real thing and don't let that beat you down because that is a balance between... This actually application, like you said, is working. It's just a matter of ensuring that you have SSL up if that's what it demands and it doesn't, it will look like it's broken. It's a big deal and you know what? I should have even kind of talked through my troubleshooting here because I didn't really. I looked at this and go, hey, it's busted. This to me looks like a page that doesn't have CSS loading and probably other JavaScript too. So what I did is I used the Inspector. I'm in Firefox. It's called the same thing in Chrome. I think if you're using Safari, maybe use a different browser for this but there's a way to turn it on. I know, it's just not on by default in Safari. So then I went to the console which is where you can see errors and stuff and you can see all of these red errors and it says content security policy. The pages settings block the loading of a resource at HTTP colon local host HTTP colon hedge doc.to. So this is a real common thing that can happen if an application says no, I must load over HTTPS basically. So that's, yeah, we can troubleshoot that further but we're gonna move on for the moment. Actually, let's see here, right? Refresh this page. Yeah, we're gonna move on. I'll have to play with this a little bit more and I'll probably update and discord exactly what you'll have to do. This is one of those situations where I have hedge doc running already. So I'm missing a step here that I would by going too fast that's looked through the documentation. Next one we're gonna look at is base row. Now that we got hedge lock hedge doc running. So base row is, I've described it to Jim before as, it's Microsoft access for the 21st century. And I ran the other way to be clear. I did run away. Yeah, yeah, I actually think this thing's really cool. I wanna, I don't know that I have a use for it at this moment, but I have used something like it called air table, which it's just, hey, this is a database like a no code database. And you can make like forms that put data into it. And because it's a database and not a spreadsheet, you can put other types of data in here. So you can see in their example here that they've got like some texts, obviously, they have like a star rating, a checkbox, images and file uploads. So you can do more than a typical spreadsheet. And you can also make multiple views into it because it's a database. And so there's a lot of things like it now, air table, Microsoft access is probably the most famous thing like this, but air table is a online version and base row is also an online version and it's open source, which is really cool. So we're gonna try to run it. I went to their documentation and they have a official install with Docker compose options. So we're gonna go that direction. This one, a couple of things in here. So looking at their sample, I'm gonna make this a little bit bigger. It's pretty simple. It just has, it's just pulling a container. You'll notice that it's also using a tag here, 1.10.2. Okay, fine. It's got a public URL defined as localhost. We may need to change that to be the reclaimed cloud URL. It's mapping some ports that make sense and it's using a volume for base row data. So it's making a volume and saying, this is where our data for base row is gonna go, fine. We're gonna actually change that and do a bind mount. And I'm gonna show you basically what a bind mount is and why you may want to use it for certain things. So I'm gonna copy their example here and I will go over to my base row container. And I forgot I gotta open the config manager, go into root and I'm going to make myself a base row folder. Again, I know I keep doing this this way and I keep saying, I'm doing this for organizational purposes. I think this is gonna make even more sense when we use bind mounts here in a second. You probably be like, why are you making a folder just to put one file in it? This is why. When you have other, more than one file, it's especially handy. So I'm gonna make our Docker compose file. I'm gonna paste in their example. Looks like we don't have to set any passwords or anything. It must have its own built-in database or something like that or maybe just doesn't need one. And I'm gonna copy my reclaimed cloud URL here. Change that from local host, the duplicate here. Okay. And we will also change this to be a bind mount instead of a volume. So if you remember in the glossary, a volume stores its data in a specific place whereas a bind mount, you can choose where it stores the data, which is really handy again for organization purposes and maybe for backup. It's super nice when you come back to an application and everything you need to look at is in one place in my opinion because often when I'm looking at something I'm running in Docker, it just kind of does its thing and I may come back to it months or a year or years later and be like, all right, how did I set this thing up? It's really nice when it's all right there for me to look at. So we're gonna define a path in the reclaimed cloud node where it's going to store its data. And this is actually pretty easy to do but I just wanted to mention that that that's what we're doing here. So instead of a volume, we have to give it a path on the left side of the colon here and we could do this a lot of different ways. We could do slash root slash base row data that would put it in the root folder under base row data. We could put it in slash root slash base row because that's the name of the folder I made or we could do something even better which is a shortcut and we can just do a period and a slash. And this means, hey, whatever path the Docker compose file that we're running exists in put the base row data folder under that which is super handy. So I do this all the time. So we're gonna do that, hit save. And then if I look here and do an LS and go into my base row folder I made you can see there's only one file in this folder right now but when I use a Docker compose up to pull the image and everything when it's done with that we can see we'll be able to see the bind mount afterwards. And this is a pretty big applications. It's gonna take a little bit. Would you liken the bound mount, the bind mount to a sim link? It is similar. Yeah, if you're familiar with the Linuxy concept of sim links it's basically, it's like a shortcut for, yeah, it's just a link for a place on your hard drive essentially. And actually I would view as volumes and bind mounts kind of like sim links because it's in the case of a volume it's saying let's take the data from this container and kind of sim link it into this specific place that Docker controls and owns. And that's var lib Docker volumes. Whereas a bind mount is saying we're gonna do the same thing. We're gonna take this place in the container and sim link it to a place that you define as a user. And there are reasons why you might wanna do one or the other to be perfectly honest. I just kind of go with whatever they're using in their examples most of the time unless I have a good reason not to. There's one example that I've done recently with our ghost installer in the marketplace where I use bind mounts there because I like the idea of having ghost whole file system of images and themes and stuff like that being right next to your Docker compose file so that if you needed to make a backup you could just zip up the whole folder and there you go. You could theoretically zip up that folder and this is gonna be the same thing with base row by the way. You could theoretically zip up this whole base row folder download it and then make a new reclaim cloud environment upload your zip unzip it and then run the Docker thing and you theoretically be good to go because it would have your Docker compose file that defines the environment and all your settings and then your base row data folder which is whatever base row needs to run. So that's a super handy method I think and kind of like to me like a really understandable way of handling the data basically. So now if I LS here you'll notice that now it made a base row data folder and if I go over our config manager and refresh we can see it there too. And if I go inside of here I can see that it made a whole bunch of stuff. It looks like it's using Postgres and it's got a folder for that and Redis which is another thing I've heard of but I don't understand or know what it is really. I think it's a database too so I'm not really sure why both of those are there. Media folder environment caddy I've heard of caddy don't know what it is and a backups folder. So maybe this is a lot of stuff that I don't need at this very moment in time but you never know if you're running base row for years and you're looking at their documentation on how to restore from a backup it might go hey there's a backups folder and there's the files you need in there. Great so now you have them accessible to you and they're in your base row folder right next to your compose file so it should be really easy to find. That's why I like bind mounts so much but there are only one way of doing things the other way being volumes. And I would always recommend when you're exploring a container for an image for the first time on Docker Hub to kind of go with their recommended path first and especially if you're having trouble getting something to work. Okay so base row is running and if I pull up the URL, there we go create a new account, bam. So I could sign up and make a new account. It smells so sweet. Yeah so I'm gonna make my account here really quick. Tonya, Microsoft access never looked so good. Yeah it hasn't. An unknown error has occurred. So this is a good opportunity to talk about logs and how do we look at logs. So because I'm in my base row folder and there's a Docker compose file in here I can run another command from our glossary I go to the handy command section Docker compose logs dash F. So basically this will let us look at all of the logging our container is doing and the dash F means continue following the log file basically. If you've ever used the tail command this is essentially like tail with the dash F flag which just says show me the logs but don't quit. Keep reading the logs in case new things enter. So you have to basically manually exit out of the logs but it's super handy if you're having questions about something that's happening. So I do Docker compose logs dash F there's a whole bunch of stuff that it spit out and it's saying hey I don't know what this means but okay great syncing base row templates. Okay fine you've got all this stuff to work with. So I could theoretically try this out here again. I'm sure this isn't gonna work because I put the same password in. I'm guessing I don't have a complex enough password. I put these things next to each other. If I look at my logs here it says back end get API post. Oh here's a bunch of stuff selects leads. All kinds of stuff happening. So I would have to look at this a little bit further. I'm to be perfectly honest I did try this out of course before recording. So I'm not exactly sure what's going on but one thing I could do is when I tried it I didn't modify the Docker compose file to put our URL in. There's a lot of different things I could try here. But that's how I'd look at the logs and troubleshoot from there is there's probably something useful in there to figure out how to proceed from here. So that's another quick application running need more configuration kind of deal. In the case of base row I would want. It jinxed you with the success statement. I don't know probably not. But in the case of base row we also have a bunch of environment files that we can look at to configure it further. And in their case here it says you can set these variables by using Docker compose ENV file. And this is basically another way to set environment variables that I don't personally use as often. But basically it's just a single file that has your environment variables defined in there. So we could do it that way as well. And yeah, and then be good to go. So I'm going to we'll return that one in a second. Or in a second to troubleshoot it a little bit later. I want now want to go to our third example which is WBO. And WBO is a whiteboarding application that's also collaborative. And to be perfectly honest, this thing it hasn't gotten updates in a long time. So I just want to check it out. It's something I heard about like a couple of weeks ago I've had on my list to see how it is. I'm interested in whiteboarding applications that you can self host and there doesn't seem to be a ton of them. There are some. But this is one I had not heard of until recently that I want to try. And in their GitHub project they have a Docker compose file just hanging out. So I have very little information on this. I've of course tried it before this we're recording this here, but I don't know a lot about it. If I look at the compose file on the GitHub website it looks relatively standard. You'll notice here that in a volume section they have actually set up a volume that's, this is a bind mount because they've defined a path and we know that because there's a slashes in it basically. So that's kind of interesting. So they're using a bind mount. The weird thing is they're using a bind mount that is at slash opt slash app slash server dash data. So basically it's sim linking from a place in the container to a place in your node that's the same path in each place which is kind of a non-standard way of doing it. But fine, there's no problem with that. The only reason I say it's non-standard is a lot of times in Docker it's nice to either put things in one folder like we've been doing or do it as a volume so you know it's in varlib Docker volumes. So you kind of have one place where your data is and this bind mount is actually just gonna make it a folder at the root of your file system at slash opt slash app. Not the end of the world because if you look at your Docker compose file you can see that that's what it's doing but I just wanted to note that this is kind of a strange one. The other one that is strange here is this has a build step and this is not something we've done before and it's also a less common thing. But basically because this has this build command and it says the context is dot which means it's looking for a particular file to tell it how to build the container. You'll note that this is because that this one does not have an image section. Most of our examples for Docker compose have a image that it's pulling down. This one is not pulling down an image from a registry. This is a very different kind of Docker compose setup. This is actually going to build a container based on some instructions in what's called a Docker file. If I go to our glossary here I have a Docker file in here and it's not real complicated but it's basically just it's a file that tells Docker how to make an image from scratch. I'm gonna put that in quotes for a reason. And that's because usually when you're making if you're a developer making Docker images you're taking a base image that has Linux installed and then making some customizations to it. So a real common thing in a Docker file is to say hey use this operating system as a base and then we're gonna run these commands in there. We're not gonna go into the specifics of a Docker file or how to make your own because that is very like on the developer end of stuff and it's not something that I've ever really needed to do to run applications that exist out there that run in Docker. But I do wanna note that is one thing that you wanna look out for because in this case it's looking for a Docker file because of that build command. And if I go back to the GitHub repository you'll note that there is a Docker file indeed here so we will need both files not just the Docker compose we also need a Docker file. And all it's doing is saying pull this image and run a couple commands and open some ports up. Okay, cool. So instead of manually copying and pasting like we have been doing because we have more than one file here I'm actually just going to, we're going to use get to clone the entire repository which will include these two files. So this is a little different process. I'm gonna click on the code button and I'm gonna click a little copy here to get this link and then if I go and reclaim cloud and to my WBO environment I'm gonna click on the terminal and I'm going to run a git clone and then paste in that URL I just got that apparently didn't actually copy. There we go. That was pretty quick. So now if I do another LS I can see that there's a WBO folder. Let's go in there. And yeah, we're just going to run our Docker compose command so see what happens. Now this is gonna take a little bit more time because it's not just downloading an image it's downloading an image and running a bunch of other steps in this case some stuff in node. So this will take based on my last test of it like a good minute or so. So don't worry if you're not you haven't done anything wrong if it's waiting a while here not giving you a not finishing up as fast as you think. So it's gonna take a second. And node is always like deprecated get a new one get this, you know, the gem file. I mean, am I thinking, no, I'm thinking of Ruby, sorry. Node two, you're totally right. Is that right? Yeah, because I was playing with, I think it was an application called wax that runs in Ruby. Yeah, gem is like a dependency manager for Ruby and nodes dependency manager is called NPM and node is famous for dependency hell in that like everything and this is true of almost any project that is a programming project which is like your code is dependent on another code but basically everything in node is made up of tons of tiny little modules. So it has to go get those and it has to do all that. It's very complex and it's all, it's kind of like a very, it's imagine a machine, a robot is building a house of cards. But it's a robot that knows what it's doing. You know, like it's a well-programmed robot. Yeah, I don't wanna make any claims about node as someone who's not really a developer. I don't really know enough to say like what's good or bad because it does mean that the cool thing about node is that people can get started doing really complicated things really quickly because they can easily build off others work. And it's not like the concept of dependencies is like only a node thing. It's HP, everything has dependencies. So it's just that node is particularly famous for NPM having to pull in a lot of different tiny packages essentially to get things working. So it did its thing. It says it image for service, WW was built because it did not already exist, fine. So yeah, so theoretically we're running here. Let me run a Docker PS says it's been up for a minute. Let's see if WBO is working. There we go. Welcome to WB. And we got this beautiful times new Roman font that you just have to see. Isn't it funny that this is the one that work? Yeah, so, well, I haven't done anything yet, Jim. All right, there we go. This is a test. Looks like it's loading something. Here we go. So, hey, it's a whiteboard. So this is, I'll say, maybe not the most polished application I've used, but it works. It's got a beautiful default maroon color. Let's try green here. There we go. We can, okay, I guess we can put text in here. Yeah, so this is one that probably, by the nature of it being kind of a, I don't know what to do with this, but okay, by the nature of it being kind of a simpler project, it probably doesn't have a lot of configuration options that we need to get started with. It certainly doesn't care whether it's loaded over HTTPS or not, which is, I think, what we're running into with the other two applications. But here you go. It's a good example of- A win's a win, right? Yeah, so I will say- We will take a win. I have, we're gonna take a second here and wrap up the video because we are at about 45, 47 minutes, but that is kind of our, gauntlet of, hey, I tried a few different applications. They're all a little bit different than NextCloud in certain small ways. Not in this video, but I will get those applications working because I can tell you that I have used all three of these before and they do work, but not in a way that I can show you within this limited time scope. So I will add that probably in the Discord of, hey, if you wanna go further with these other than just making them run and you wanna actually configure them in a way that you could make documents and things, I'll have instructions on how to do that and what you might need to do. But hopefully this was helpful as a kind of, a peek behind the thought process of, all right, I found an application. How do I get it working with only the knowledge that it supports Docker in some way? I like it a lot because it gives you A, exposure across various applications, B, an insight into binding versus volumes and what a bind mount looks like. C, the Docker file, when there's not, you're not actually pulling in an image. Like it's building it from scratch. That stuff, like as you were talking about it, really started to click for me. So there's a lot for people to learn by experimenting with these three applications and that's week four. Experiment, see what you can get up and then on Friday we'll meet and talk about what worked and what didn't and why not. Yeah, absolutely. The other thing I wanted to mention too is if you have an application that you wanna try out, obviously go ahead and do that and please share your progress or struggle or whatever in Discord so we can all learn from it and I can maybe help you out with it if you have questions. If you don't even know where to start with it, if you're like, here's the thing, I think it might work in Docker but I don't actually know where to get started. Just post that in Discord because I'm looking for, I wanna help some people get some things running. So whether that's this week or if you're a little bit behind or you just have not have time this week, feel free to share that in our Understanding Containers channel or else we're on the Discord for that matter. I want to, it's my goal to help people run things and do cool things. So if you have an application you wanna run, let me know, we can try to see if we can get that working. Yeah, thanks Taylor, that's awesome. Week four, Understanding Containers, big fan.