Coding Blocks - Docker for Developers

Episode Date: May 1, 2018

This episode we’re talking about server naming conventions, confusing command line arguments, and how high we can get our voices. Huge thanks to the NSA and the freedom of information act for making this episode possible. Sponsors Airbrake.io/CodingBlocks – Try Airbrake *free* for 30 days _and_ get 50% off the next 3 months! Survey Says […]

You're listening to Coding Blocks, episode 80. Hackers have corrupted the computer. You are listening to the recorded backup provided by the NSA. I'm Alan Underwood. I'm Joe Zach. And I'm Michael Outlaw. This episode is sponsored by Airbrake.io. When your website experiences an error, Airbrake alerts you in real time and gives you all the details you need to fix the bug fast.

And setup is really fast too. I actually posted a video to our YouTube channel where I walked through setting up Airbrake from scratch for a front-end JS app. The whole kit and caboodle took about a minute and would have been even faster if I hadn't added some custom data for them to track. Right now, CodingBlocks listeners can try Airbrake free for 30 days, plus get 50% off the first three months on the startup plan. To get started, visit airbrake.io slash codingblocks. That's airbrake.io slash codingblocks. All right, and tonight we're going to be talking a little bit about DevOps, containers, Docker, and why you as a developer should care.

But first up, got a little bit of news here. So say, Alan, you want to tell us about iTunes? Yeah, we have a few reviews here. We had in Markora, let's see, Scaliluja, Scaliluja is what it is, I'm sure. And I'm not sure how I got here, which I love that one. And Sapphira 80. Yep. And over on Stitcher, we have Ivan the Terrible, Stickers Please, Column Fairy, and Samantha Blank.

And if you were Stickers Please, please send us an email and we will, we will hook you up. Yeah. And Hey, one, one last thing we want to talk to you about real quick. We just released our very first coding blocks community talks, which was a video where we gathered some people that we know from the Slack channel, some of our favorite people. And we got together and we talked about over architecture and we recorded the whole thing and threw it up on YouTube. So we'll have a link in the show notes here.

Just go over to YouTube and search for over architecture and check that out. Awesome. All right. So let's dive into the beat. So first, I want to start with just a little kind of condensed history left so we can kind of set up the rest of the episode. And I want to talk a little bit about kind of what DevOps means today and how we got there. So in the beginning, wait, wait, before, before we say in the beginning, what is DevOps? Because this is like a buzzword that I don't think not necessarily everybody knows. Anybody? Mike?

I got nothing. Oh, come on. Well, yeah, I was trying to think, like when you said like a good way to describe this. If I'm put on the spot, I guess it would be like developers doing your build deploy operations by code. Yeah, it's like developers for developers, right? It's the people enabling you to do your development easier.

Yeah. Maybe the older way of doing it years back would have been you had administrators who would install and configure and build a machine for you. Maybe not in that order. They might build it first. And they would be responsible for all the network and everything. And now you're like, hey, here's my shiny new software. And they're like, okay, great, we'll go install it, and we'll let you know if we have any questions about how to configure it. And now it's like, hey, you know what? I'm going to spin up these virtual machines or Docker images or whatever programmatically.

I'm going to script all this out. I'm going to try to save my environment as code. Right. Yeah, just because when I first heard that term, I felt like it was being thrown around a ton. And I was like, well, I don't know what this means. So hopefully that helps somebody out there. Yeah, and I think that we're going to be talking a lot about DevOps.

So you can kind of think of this whole episode as really being DevOps focused. And just like Ella said, like in the beginning, we used to order servers. And that was a big process because you would kind of guess how much RAM we needed. And you would order it. It would have to get it signed off. And then you would get the machine in. Somebody would have it in their office for like four days while they installed everything and hard DOS and yada, yada. And it was just too slow.

So along came VMs. And we're like, okay, tell you what, we're going to buy a beefier box. And then we're going to set up a bunch of VMs on it so we can kind of spin these up more quickly. So instead of sitting on the boss's floor for four days, we'll just have it in a closet over here. And we'll only spend four hours whenever we need to do server. It'll be great.

But that was too slow, too. So then the cloud came around. Really, before the cloud, we just started renting them. So we're like, why don't we just get a co-location center somewhere where energy is cheap and space is cheap, and we'll kind of remote in, and we'll just buy more servers when we need them or rent them. And you know,

that way if we need to shut these servers down, it's only like a couple of weeks rather than us just being out of luck. If we don't need something anymore, we get new servers all the time. There were a lot of benefits to that. And, and what this was called, if you guys recall,

right, we're like VPS, right? Virtual private servers so that you get your own and you'd have your own virtual CPUs. You'd have your set amount of RAM and all that kind of stuff. That might even be like a step before

where I think maybe Joe was referring to, right? Maybe I was like going a little step ahead in my mind then as he was saying it, I was thinking of like VMs and say an AWS or an Azure or something like that, right? I think that's the next evolution. The VPS is totally, I totally skipped that step. You're right. Yeah. So then I guess the next evolution would have VPS is totally, I totally skipped that step.

You're right. Yeah. So then I guess the next evolution would have been exactly what you were talking about with, you know, now you got AWS and you could spin up a VM or whatever. So, yeah.

Yep. Yeah. And so that's kind of like the current state of things. But one thing I kind of thought was so funny is like none of that stuff really went away, right? Like there are still

servers sitting in closets today. There's still co-location facilities. There's cloud and there's like companies have a big mix of things i don't even know if we have an existence yeah vmware still makes a lot of money doing this stuff yeah absolutely and uh what i thought you know in addition to that too is life didn't get really easier at all because of any of those things like you would think like hey it takes us four hours to set up a server now instead of four weeks like you know we should be rolling we should be playing foosball all day but really what happened is you know people just started expecting more and the products we had to deliver were more and more

complicated and the developments got more and more complex and Suddenly, it's like, oh, well, if I can have eight computers on a computer, well, suddenly, I need nine, right? And so, you know, even with the cloud itself, like, there was a big evolution there where we started out with, you know, infrastructure as a service, IaaS, where we rented EC2 instances or servers. And then along came platform as a service, like Service Fabric or something like that with Azure,

where you kind of it was a little bit of kind of halfway between IaaS and what came after, which is software as a service, which is just kind of a service that you can rent and pay like per query or per usage, really. You don't even have to have a server anymore, right?

You just kind of pay for your use with several of those functions. Yep. And everything exploded. Haha, just kind of pay for your use with several of those functions. Yep. And everything exploded. Haha, just kidding. So this is where the DevOps kind of comes in. Programmers are really smart, at least

not me, but other people. Other programmers are really smart. Wait a minute now. You might be giving us too much credit. And as long as this kind of more complex environments was growing, the tools were maturing. And so Jenkins came into being. I don't

know the history of CI, but I know there's a long path starting with Make back in the 70s or 60s or whatever. And Maven and all the build tools, Griddle, have come along since then. Ant. But all along the way,

the developers have been maturing these tools. I'm surprised you didn't mention Chef and Puppet in those. Those guys are still kicking too. Especially as it relates to trying to do spin-up instances

inside of an Azure or an AWS and script that out. Yep, absolutely. And I think that scripting out was a big part of what I think it was as DevOps is kind of taking more and more of that work that used to be done by people and getting it into code that we to be done by kind of people and uh getting it into code that we can actually check in and version control and so that's where things like you know the puppet recipes come in or the chef recipes rather than puppet whatever they call those um and uh you remember cloud formation that was like amazon's aws's way of kind of defining a

whole architecture in like a file so you could kind of spin up and use it to keep your different environments in sync. A really big, gross JSON blob that you couldn't read. Right. And that you had to dig into documentation to figure out what it actually meant and did. But no, yeah. Right. Yeah, I think that this...

It seems to me, though, the whole DevOps kind of terminology came about about trying to save your configurations as, like being able to version control your configs. And make it faster and less human interactive, right? I think that was... Reproducible is another way to say that. Yeah, a key piece of it was taking people out of the equation

because as we talked through these first bullet points here, one of the big things is it wasn know, it wasn't so long ago when if you needed to deploy a website, it'd be like, yo, hey, Joe, will you build that on your machine and provide me a zip file or something? Let's go lay it down over here, right? And that was kind of the way things were done for a long time. You might have a little bit of automation,

like you might push something over here and it would get copied out to some other servers, but there was almost always somebody involved. And this is sort of taking that out of people's hands and putting it into a machine. Yeah, I mean, I feel like part of this also spawned from not really fully utilizing the underlying hardware either. So going back to Joe's,

where Joe started this was, you know, in the beginning, there were servers kind of conversation, right? You know, when we bought those servers and, you know, you had to wait for it to get built and shipped to you and then your admins would have to do their, you know, install and config of it.

You know, I mean, it would be weeks before you actually got to use that thing, right? And then once you did finally use it, I mean, it would be weeks before you actually got to use that thing, right? And then once you did finally use it, I mean, you were only taking a guess at what the specs were that you even needed on it. Like, you know, well, I think we're going to need about this much memory, and I think we're going to need about this much CPU.

But you also had to like worst case it, right? You're like, well, you know, based on my peak traffic, I'm going to have to really, I'm going to need more RAM or more IO or whatever, you know, the case may be a disk IO, network IO, whatever. Uh, and really over provision that hardware. Right. Uh, I mean, I've been in environments where we would have like, you know, six fiber channel cards, right. For disk IO, you know, like just just just for disk io with with you know twice as many ethernet connections bonded together just because well for worst case scenario we need to make sure

that we're getting the bandwidth that we need in you know multiple you know both network and disk right um and that was all for worst case scenario. But so, you know, what that means is then like, you know, at midnight, you have this really expensive piece of hardware that's not being utilized at all. to it, maybe a little bit more beefy, and we could run two VMs on it and better utilize that piece of hardware. And then services like an Amazon came along and were like, hey, you know what? We still have utilization we're not using. How about I slice off a piece of that and I rent it to you as infrastructure as a service, And now you can use that too. So it kept, it kept building up from there. Right. And you know, the funny thing about it is, I guess just tacking onto that is the reason

they would overbuild those things too. Wasn't just, you know, we know that we're going to need at least X amount of utilization and you know, this is the baseline, but they would also overbuild those things, especially when VMs came into play because heating and cooling, or not heating, but cooling down those things is expensive, right? And so the fewer of those things you had running in a rack, the cheaper it was for you to run that. And also rack space is expensive, right? So the more of these things that they could cram into a smaller place,

the less the cooling cost, the more they could utilize those boxes and get the most out of them. So it's this complex problem that most of us never have to think about that has just sort of kept rolling downhill. Yeah, actually the definition from Wikipedia here on DevOps is basically the main characteristic of the DevOps movement or philosophy is to strongly advocate for automation and monitoring of all steps of software construction,

from integration, testing, releasing, to deployment and infrastructure management. And I think that makes it sound really easy. Even though what we talked about with evolution, it kind of sounds obvious in hindsight. But man, that's hard. I'm sure you guys have been working somewhere at some point where somebody said, hey, we need to restart

the web server. And you're like, wait, was that on Leonardo or Donatello? Because you don't remember which server the VM is on. And of course, you run out of turtles. At some point, you get that fifth server. And then you've got to come up with a new naming scheme. That's why you got Hermes.

Wait, what did you say you had? Hermes. Didn't all organizations you say you had? Hermes. Didn't all organizations name all their servers after Greek gods? At one point in time, yeah. It was kind of ridiculous stuff, right? Yeah, it was like Titan. I know that wasn't it.

You ever had a Sneezy or a Sleepy server? No, no. No Seven Dwarfs. What? No. Thundercats maybe. Thundercats. Yeah, Panther. Absolutely seven dwarves. What? No. Thundercats, maybe. Thundercats. Yeah, Panthro. Absolutely. I've worked with Panthros. That's awesome.

More than one. So, you know Google wasn't doing this, right? Even probably in the early days, a couple years after launching the site, they weren't like, Hey, Steve, get that fix out. Hurry up. Deploy it on boxes 9 and 10. Doesn't work like that. No. Well, it all started

somewhere, but I digress. So, yeah. The next part that he has here is programmers working on the most complex architectures in the world attack this from two sides. Right? Yeah, and I made this up. I didn't find an article that said, hey, here's the two solutions, but this is, as best i can tell like programmers came at it from both sides like

the they built really complex orchestration tools like now we're talking about like kubernetes and swarm and stuff like that but even before that we know we had like helm and ansible and like you know you can go way back to octopus and anyway the long list of stuff so we built really complex orchestration tools that were able to manage those environments faster more efficiently than people ever could but we also attacked from the other way right we standardized and simplified our deliverables so we wanted to give like a single artifact or a small collection of stuff and that's kind of where our focus is tonight we're talking about that side of things because let's face it we're not all working to

google right most of us aren't by a long margin and so a lot of these tonight. We're talking about that side of things because let's face it, we're not all working at Google, right? Most of us aren't by a long margin. And so a lot of these things that we're talking about like the auto scaling and the Kubernetes and these really core orchestration things, they're just not practical. They don't apply. And frankly, it's a waste of time for a lot of developers to really invest time

there because it just may not be applicable to the situation and won't ever be. And it can be incredibly complex right like incredibly complex when you start managing all these orchestration builds modularity all like yeah it can turn into a lot of work it can be more than just a single person's full-time job to manage that stuff and make sure it's efficient flowing you know you have your monitoring on it and all that kind of stuff. I mean, you think about somebody like an Amazon

who has a massive pipeline in place to where when commits happen, like it flows all the way through, there's stop points, there's all kinds of things that happen, right? So it's not a small job when you start really dealing with any amount of code. Yeah, and for a lot of businesses, of businesses, we joke around about building on Steve's laptop or whatever, or Sandra's laptop. And if Sandra's on vacation, then we just don't build. And maybe that's okay for a lot of organizations, and maybe that's just fine. But that doesn't mean that you can't benefit

from the simplifying and standardization aspects of containers. That's where we're kind of hopping into next. So basically, what are containers, what they're for, and how they can help out, even in situations where you're not operating at Google scale. So let's dive into what are containers. Yeah.

And this one's kind of interesting because everybody wants to kind of bundle them with VMs, right? If you start talking to somebody about Docker or containers or anything in that realm, people are like, oh, so they're just smaller VMs. that's not it. When you talk about a VM, you were talking about the whole kit and caboodle, right? Like you have an entire OS being virtualized on top of the hardware. So if you're talking about a VM like Windows Server, then you've got a brand new fresh install of Windows Server running on the hardware. If you have eight VMs of Windows running on the same box, you have eight full-blown installations

of Windows Server. And that may not sound bad until you start thinking about security patches. Or if you scale it. If you need that, if you create a virtual machine on that box and it needs one gig of RAM, then when you spin that thing up, it's going

out to the physical hardware and it's reserving that one gig of RAM. So now the host no longer has the ability to use that. That's okay. But now you spin up a hundred instances of that virtual machine. You now have used up a hundred gigs of RAM that the host had to have already and now can't use because each of those VMs are using it and they might not even be fully utilizing it. Yeah, and just to point out, because I'm sure somebody's going to come back to us, things like VMware have made it to where you can over-provision a box, but by and large, it does work that way.

The biggest problem, though, is it's scaling. First, it's slow because you have to have a full-blown OS installed. Whether you image that thing or not, it's still going. It's slow because you have to have a full blown OS install, whether you image that thing or not, it's still going to be slower. You're going to have a startup time of minutes, you know, Linux could be a minute. Windows could be several minutes.

And you're slowing down the host. You're slowing down the host because all that virtualized drivers and stuff to get to the hardware, like it's, and you're overusing a lot of the resources available just to run the OSs. And now that doesn't even take into account patching, security upgrades, all that kind of stuff.

It all has to happen separately. Right. Now, not just one host operating system has to be patched for that Patch Tuesday security fix that Microsoft just released. But those hundred VMs that I referenced in that example also have to get that patch or they are vulnerable on your network. Yep. And so that's where I,

hopefully that paints a picture of what a VM is. It's basically like having a separate computer, except we have a bunch of them running on the same hardware, right? When you get into a container, it's just a process that runs in the OS, right? Like if you spin up a Windows Server core container on Windows Server, all that's doing is leveraging the existing operating system,

but running another process that's basically your container just, and then spin up time is really fast depending on what you've got. And here's the thing that I always found interesting every time that I listened to container talks is they would say by their very nature, they are typically more secure than a VM. And if you think about it, it makes a lot of sense because the attack surface is so much smaller. If you make sure that one VM or the server,

if you're running on the hardware, it doesn't matter, right? Whatever the host OS is, if that thing is patched and updated and security locked down as best as possible, your surface, your attack surface into that container is really small. I still work to get it there, though. Typically, when you run a Docker, at least in development, you're generally running as root inside that container. And there are reasons why that's not as scary as it sounds.

It's kind of locked down in its little jail and can't do stuff. But there are things that it can do that you may not want to do. And so it's still kind of scary to do that, I think. But what do I know? But going back to when we were talking about the VMs, right? You allocate a gig of RAM to each one, right? Now you've taken up, you know, 100 gigs of RAM on a server, which isn't, it's not a cheap thing even nowadays

to buy 128 gigs of RAM for a server. Although for anybody that has not been to the Stack Overflow, how they design their stuff, man, if you look at the specs on some of their servers, man, there's some cash luck in those things. I just want one of their desktop builds. Oh, man. For the developers.

Oh, my God. They're incredible. I'll have to find the link and share it on here. But what I was going to say, the other thing about containers that is really interesting is they, unlike VMs, try to only use what they need, right? So if you provision a hundred containers and these things are set up to where they can take up to a gig of RAM, if they only need a hundred K, they're probably just going to sit down there and hover around a

hundred K or a hundred K. And then whenever they need more, they'll go get it, right? But then they'll drop it back off. And so you can better utilize the resources of your hardware because it's constantly scaling up and down. It's way more elastic in terms of the resource management of the container itself. Yeah, I want to mention too, we're not going into details here. And pretty much anything we say about containers, there's got to be a little asterisk on because it gets really confusing into the weeds depending on your implementation and whatnot.

And even saying containers, the notion goes way back to 1979. So when I say container, depending on who you're talking to, what the context is, it could refer to any number of things going back that far. And I also want to point out that whenever we say container, we

don't mean Docker. It's kind of funny. A lot of times you say container to someone and they start thinking VMs or you say container and they start thinking about Docker or you say container and they start thinking about any of these other CH roots or whatever that have come out in the last

however many years, 1979, 40 years. So we got to be really careful with that. And so we don't want to go too deep because even talking about micro kernels and different operating systems, like when I spin up images on my computer, you know,

windows, I've got bash there. So like, you know, I'm running some sort of Linux somehow, somehow, some way. So it gets really kind of squirrely if you try to talk

about the details because it does get really specific really fast. Yeah, I agree. But why do people, why is Docker become it? Do we even have a, I don't remember seeing a bullet in here for that, but why is it that Docker has become the Nintendo of video games or You know what I mean? Yeah, I've got some opinions on it. I don't know how accurate they are, though. Well, just based on the courses and stuff I'm watching. I mean, jokingly, I was going to say hashtag winning. But I think maybe part of that is just because

there's a company behind it, you think? Maybe that's one of the reasons, because they have a motivation to make it so. That might be it. That's possible. Yeah, so I'll just tell you the reasons I came up with it. Basically, Docker is a whole ecosystem, right? So it's a company. So there's a...

They might be non-profit, I don't know. But there's a large group of people, a ton of employees that are behind this thing. They're marketing, they're throwing dollars at it. They're out there doing webinars right now. It's also command line tools that are really nice and elegant and they're well-documented. There's a lot of open source stuff behind it. So there's a lot of documentation about it.

They've got really nice orchestration stuff that's kind of been taken over a little bit by Kubernetes, which is Google, but it does kind of play a nice there. But I think a big part of the reason that they won was just Docker Hub and the documentation. So they made it really easy to kind of create this little file and it would go out to their website and grab these images that other people were making. So if

I wanted to play with Elasticsearch, it's kind of a one-liner. And they made that happen. They put that ecosystem together. So it really reminds me a lot of GitHub is Docker. And even Git in a way is like it's source control. It's one solution to a problem. Like containers are source control.

And Docker is like Git. You know, it's one solution for the problem, but it's winning right now. Hashtag winning. So, yeah, I mean, it sounds like they made it easier for people to use containers is what it boils down to. More so than anybody else that came before them, right?

Yep. And just like containers, it's kind of hard to talk about because when I say Docker, I may be meaning the company. I may be meaning the Docker hub. I could be meaning literally the command Docker or could be meaning literally the command Docker dash compose, which is kind of a different thing.

And so it just gets really confusing. And so whenever we say Docker on the show, just know that we mean all of that. Or, you know, some mix. Make it fit the given context, and that's what we mean. Yes, that's right. And that's why we're not going to try and teach you Docker on this episode because it's pretty crazy,

and there are a lot of really good reasons out there out there for it but we can talk a little bit about what docker means for developers and i think that's really important yep and so for most developers i i think of like a container as being like a portable shipping container that holds my application and that most importantly to me it lets me treat as a single modular unit so i can define like these ports and I can define these volumes, these hard drives, and I kind of can compose these things together and plug and play and treat them as these like units when actually we know behind the scenes,

like apps are really, you know, big, crazy, confusing things. Like I'm sure if you've ever seen like a, you know, if you would open like on a Windows computer,

see program files go into a game or some directory, like you open up and there's like a thousand DLLs in there. You know, if you compare that experience to like finding a simple app on like a Mac that's been bundled together. And so you see like a single DPG file or you see, you know, you can do it on Windows too, like a single EXE file where it's all kind of bundled up. It looks nice and tidy.

And, you know, if you want to uninstall it or get rid of it you just drag the one file over there so i i want to expand upon that just a little bit the whole thing that it's like a single modular unit it's in it's in its own container is i think it'll make it more clear if you think in terms of what an application typically is because just for instance like if you took a simple node.js type thing right a lot of times you're going to have node.js installed on your computer like if you've ever decided to go play with something and you said well i want node well what version do i need do i need 4.1 do i need 5.5 do i need 6.5 what do i need right that you're going to have to install, right? And then what if you have a conflicting version on your computer? Like, what do you do at that point? Do

you uninstall your old one and install your new one and possibly break your old application? Like, that's the kind of stuff that happens. You know, what if you have a particular database that you're working with, whether it's MongoDB or maybe MySQL, and you had an older version, but now you need a new version or vice versa, you need an older version, but now you need a new version or vice versa, you need an older version for what you're doing. Like, that's the kind of stuff that the container solves. Because now what happens is, instead of installing those things on your machine, those things are baked in to the container, right? So you say, hey, I want node version six in this container, and I want MySQL 5 in this container, right?

Those things are installed in the container, and your computer doesn't even have to have anything that would, like Node.js doesn't even have to be installed on your computer, right? It is in that container. It is something that you can run just like it was another process, just like it was another computer that you're sort of logging into. Yeah, I was thinking of it. I'm trying to remember the term for it, but I think there's some kind of term for something like side-by-side dependencies or something like that. Does that sound familiar?

Where it's like, you know, you can have all of those things that need each other close together, which is kind of the way like with C-sharp and, or let's back it up, not even C-sharp and say with.NET, right? It kind of went away from that with things like the global assembly cache where, you know, you'd have DLLs in random places, right? Instead of necessarily being right there beside the EXEs that need them. So, you know, what you were describing before is that if you had, if you only had your DLLs in one place and you could have those conflicting DLLs, it's like, well, which I can only have one of these installed.

Which one do I get, right? And with the things like these containers, you could have multiple instances of these containers, each with different versions, and they can have their dependencies. Whatever that application needs can be baked into that container or for whatever purpose you built that container for. It can have its dependencies baked into it. And you can have one that is, you know, you mentioned a node five versus a node four, six, something like that. You know, you can have those two versions of that container that had different

versions of node. Yep. And, and this goes back to a previous episode where we brought up blazer, right? Like that's a really cool thing. Well, one of the things that i don't know if i want to call it a problem but one of the side effects is if you want to play with blazer guess what you need the latest preview version of the dot net core framework and people that have real work to do the on on like maybe their bread and butter application you don't necessarily want to install the preview bits on your machine.

Or your bread and butter machine. Yeah, exactly. And so a great way of doing this is, hey, let me get a Windows container. Or it doesn't even have to be Windows. It can be a Linux container. And then we put.NET Core in it with the latest 2.1.3 preview. And guess what?

It doesn't affect what you have on your main machine. It is only in that case. It's almost like this little tiny computer that's running in the background that you can just blow away whenever you want because I think we even skipped over it. The whole point of containers are they should be ephemeral.

They should be able to be short-lived. Like literally think about it like this. It should be, if it was a computer sitting in your room, you should be able to pull the plug on it and not care. Literally pull it out and then plug it back in and start it back up, and it doesn't matter. Well, it's like your toaster or your telephone. Well, old school telephones.

You should, right. Not modern cell phones. But yeah, just go to unplug it, turn it back on. Yep. Yeah, I actually ran into that problem with Blazor. I wanted to play with God Prog Man's PokeBlazor app because I wanted to give it a shot. So at first I went and did

the upgrade of the preview and then I went to try to go back to my old app and it wouldn't work. And so I ended up actually writing a Docker file and checking it and doing a pull request to him, specifically for Blazor. So now if you want, if you've got Docker set up, you can go play with Blazor on your lunch break because you can just download the

you don't even download the image. You download the file, the Docker file. Assuming you have Docker running, you just run it and it'll go and download everything for you, set it up and start running. It's really nice. I really like, too, the nature of the Docker files and the Docker Compose files. I open up a file and I'm like,

oh, here are the ports you're using. Here are the outputs. Here are the're using. Here are the outputs. Here are the directories. Here are the volumes. Here are the network connections you expect. So it kind of serves as that cloud formation file that we kind of talked about where it says like, okay, here's all this stuff. But what I like about it and difference is like it kind of

only shows me the important stuff, the things that kind of differ per installation rather than having a bunch of like kind of boring stuff that nobody cares about in those files. So you tend to be really small credentials. Right. Yeah. Right.

Sorry. I didn't mean to intercept. No, good. So, um, one thing, one term I keep hearing come up or one phrase is it eliminates a whole class

of problems. I've, I've probably listened to like three different Docker courses at this point, maybe even four. I've listened to every podcast on subject and his phrase has come up at least once in every single one. And so I wanted to get your guys' thoughts on kind of what that meant. Eliminates a whole class of problems.

Um, I mean, I've got some examples I can tell you, but I just feel like, right. Doesn't that phrase kind of suck? Like you kind of know a little bit what it means, but to actually like put something behind it, you know, it's kind of weird.

Yeah. It's trying to put, you're trying to put some meat behind that statement. And you're like, okay, I kind of get the intent. Right. But like, it's almost like when you write code and somebody's like, it just doesn't work. It's like, wait a second.

Right. Something works. Or better yet, you have some code and you're like, it just works. Yeah, of course. Whenever I hear that phrase, I'm like, oh man, those guys have been drinking the Kool-Aid just like I'm drinking the Kool-Aid

when I watch the courses and stuff. You can tell that phrase is somewhere in the marketing materials at some point and it's been propagated ever forth. But I think it does have meaning and I think it's a good meaning. The idea is that it gets rid of those works on my machine kind of things.

Right. In cleanup, I used to work on a product that would change stuff in the registry. So if you worked on it a little bit, and then you got a ticket, and it's like, hey, you got to work on the old version. Ooh, now all of a sudden I got to know what kind of weird stuff it's doing in the registry because there might be some sort of overlapping meanings there or values that change. And it actually reminded me of another problem, too.

Back in the day when I used to work on Java a little bit, it'd be like, okay, hey, our app is upgrading from 1.6 to 1.7. So first of all, you got to go to the website and make sure to uncheck that ask toolbar crap. Install Java 1.7 and like, okay, now we need you to work on this ticket in the old version.

You're like, okay, well, let me go unset my Java home and now you got to fiddle with that stuff. Like now in the kind of the Dockerized container world, I would basically try to get both of those environments set up. So if I need to switch between branches, heck, if I want to spin both websites up at once, it's trivial, right? I basically just fire up two terminals or even the same terminal,

just go and fire up both full architectures. It's not like, you know, we're talking about containers as if it's one little thing, but there's nothing stopping you from spinning up a ton of containers all at once. And that's kind of getting out of the reach of this, you know, it's getting into the more of the orchestration side. So we don't want to go there too much, but it's just really powerful. And we're going to talk more about the practical aspects coming up here. Yeah.

Hey, before we go any further, though, one thing that I think is important that hung me up on specifically Docker, but containers in general, when I first started messing with this is you start thinking about, wait a second, can I treat this like a VM, right? Like, oh, I can just put stuff in there and run it. Like, I do want to point out, though, that typically it's either a daemon, like a background process that's running, or some sort of framework that you're trying to leverage. Like, it's not the type of thing that you're going to go install Firefox into

and try and run Firefox out of your container. Now, there are people that have done that. So I don't want to act like you can't because there's clever ways of doing like an SSH and tunneling, you know, things in and out, but that's not the intent, right? The intent is to have like an environment, a nice environment set up to be able to host your application is a lot of times is the way I try and think about a container, right?

Yeah. And you know, that's a really good point too because there are things I would never do with VNAT VM. Like I would never as a developer say, okay? Yeah, and that's a really good point, too, because there are things I would never do with a VM. I would never, as a developer, say, okay, hey, I'm going to spin up this VM to run this one command, like to run a build, for example. I'm not going to wait for that seven minutes for that VM. No one

likes working with VMs. No developer's working with a machine on their computer. Wait for it to spin up, run the command, and then shut back down. No way. But a container, I can do that because once I've got that thing kind of warmed up and I tell it to build, it's only going to do that top layer, which layers is a whole other big subject. But the gist is that because there is that overhead of the operating system,

it can kind of just jump in at the point where it actually needs to make a change and do that one thing. So it's lightning fast. And the resource usage, just as you said, I don't have to allocate two gigs of RAM to run my little process to do a build or whatever. And yeah, VM stink. Could you imagine doing something like building a VM

in the first stage of a CI pipeline and then uploading that four gig or whatever VM and testing? If you're lucky, four gig. Right. Yeah. first stage of a CI pipeline and then like uploading that 4 gig or whatever VM and testing. If you're lucky, 4 gig. Right. Yeah. That would be like the operating system only and that would be like an old version of Windows. Yeah, that's Alpine actually. You're going to get that in there. Yeah, and then if you're doing something in the cloud, then you may

run some sort of weirdo process or something to kind of take that VM and like kind of cloudify it and turn it into an image for like AWS or something and then kind of get that up there. kind of cloudify it and turn it into an image for like AWS or something and then kind of get that up there. And then at that point, you can go and start kind of deploying that image up. And then what do you do? Like remember the old days, you would like kind of spin up these VMs running the new software, and then you still got the runs running the old one. So depending on your load balance when you shut up and yada yada,

how you handle state, you either start swapping those guys over immediately or it's just really annoying. And now in a Dockerized world, I guess that's where the Docker swarm kind of community stuff comes into, which is really hard not to talk about because that really is a huge benefit of doing this. But I did want to focus in this episode on the developer aspect because like we said, you're probably not working at Google. Yeah, but so here's the thing, though, and I know we're not going to get into it on this episode,

but it's worth knowing, right? Like the hierarchy of if we're going, if we're seeing this how we're talking about Docker, specifically, even though in the context of containers, there is a hierarchy. At the very top, there's the Docker, right? There's the one image, and then that can spawn off multiple containers of that image. Down below that, typically the next thing you'll fall into is like Docker Compose, right? Which is being able to

compose several Docker things to be able to talk to each other and be aware of each other, right? And then what typically happens is then you start looking at, oh, well, there's Docker Swarm, there's Kubernetes, there's actually a bunch of other ones as well. The reason why it might actually be important to be aware of, though, is when you start looking, if you ever do decide to look at the cloud, which it's not going to be long before you'll be in it if you're not now. The ones that they typically use are Kubernetes because Google has spent a lot of time building that thing up or Docker Swarm because Docker is trying to get that into the ecosystem, right? So where you really run into this thing is maybe not on your own playing with it in terms of like, would you ever need it? Docker Compose would probably get you 99% of what you need to do. But as soon as you start playing in a cloud environment, Kubernetes is going to be huge. And you'll typically see that K8S referred to.

So I just wanted to throw that out there so that you don't think that, because if you just go down one path and that's all you're focused on, you're probably going to get frustrated at some point. Just know that there is sort of this hierarchy of how you end up growing this thing out as you learn more.

And Steve Smith likes to talk about pain driven development. Like when something starts hurting, that's when you start looking for another way. And so we're trying not to overwhelm you. And like, there is definitely a learning curve, you know, and it's so funny.

Like whenever containers comes up, like inevitably Docker comes up and inevitably the K word. Right. And so it's like, Oh man, can't we just talk about one freaking thing at a time? It's nice to know how they relate. Even if you don't deep dive in. It really is. Just so you know, right? So Docker is your single image and many containers. You can create 50 containers

that are all running Node.js 5 off that one Docker image. Well, how about let's back that up just a little bit for people who are brand new to it at all, right? And you're trying to come up just a little bit for people who are brand new to it at all right and you're trying to come up with a difference between the image and the container you've made a disk image before right and you could copy that disk image with your friends and you could all mount that disk image right so so there's the one image but that thing can spawn multiple containers right running containers yeah right their containers are the running instances of the image yep and then when you go up to a docker compose it let's uh let's uh take take joe's elastic search thing that he talked about earlier and and he's got experience with this typically there's

this whole elk stack that comes along with elastic right, right? Elastic, Logstash, and Kibana. Elastic is where you have your indexes stored. Logstash is how you ingest things from other places. And then Kibana is sort of like your GUI for it, right? And the cool part is, is if you want Kibana to work, then you have to have an Elasticsearch server running to be able to use it. Well, if you try and hand jam all that stuff with Docker, you're going to spin up one over here. Then you have to go and try and run this Kibana thing. And then you're going to have to figure out how to make it talk to this thing.

Docker Compose allows you to do all that. It'll kind of start up an entire cluster of things for, I don't think I want to call it cluster because that gets confusing with Kubernetes. I mean, you can do clusters with Docker Compose and Swarm and Kubernetes. That's the frustrating part, right? Like there's a lot of overlap. Once you start getting in Docker Compose, there's overlap.

But the key is, is you can literally set up different, think about it almost as servers, we'll say, that can depend on each other, right? So Elastic cranks up and then it knows, okay, Elastic's done. Now let me start up Logstash. Okay, that's done. Let me start up Kibana. And it has like this dependency chain, right? And that's where Docker Compose is really interesting. But then you get into Kubernetes and that's when you start talking about scaling this

stuff out to a billion users. So that's, you know, hopefully that draws a picture a little bit. Now we've got Alan's attention. Yes, the better users is definitely the end goal. Yeah, and we should mention too that you can run this just about anywhere. So if you're on Windows 7 up, there are a couple other restrictions. Like you have to have x64, you have to have a hardware visualization. But I think if you're on just about any flavor of Linux or Mac,

you're just good to go already you'll have to install something but version Unix from like the 70s you're okay but I like how you referred to it as as Windows 7 up because man I'm on Windows Sprite so I guess it's not the limity line yeah yeah I you, I will say this is one thing that's really important to note. The virtualization needs to be enabled on the hardware. Oh, man. So. You had to say that. You had to go there.

It hurts me a little bit, but there's a couple of things. And I'll let Mike take the one that's painting him. One thing that for whatever reason, I never really got until I started really playing with this stuff is when you create a VM, like let's say that you're running Windows, right? And you wanted to create a Linux VM on top of Windows. It seemed easy. If you ever try to go that extra layer in and say, hey, well, I want to create a VM inside that Linux thing, you're probably done. It's not going to allow you to do it because there's like, and I know if people overuse this thing, but this whole inception thing where you keep going down deeper and deeper, there is a virtualization

layer that lives on top of your hardware, right? And then so then that gets used by your VM. Well, once that's been done once, it doesn't like to do it again for the most part. So you actually sort of have to plan this thing out a little bit sometimes, you know, like determine what your host hardware is going to be, then your host OS, and then whatever else you want to run on top of that. And Mike, I'll let you take the pain. Yeah, I mean, this is a painful subject, and I'm going to have to like pour one out here because, you know, for a long time, I've been a fan of the macbooks as my as my drivers but

working with docker docker has been one of those things that's making me want to like go away from it like really yeah it's weird right because it's not working great for me because here's the reason is if you stay in mac os ignore everything i'm saying because inside of mac os everything is great it's beautiful whatever but uh i boot camp my machine right i mean that that's one of the reasons why i've advocated for the macbooks is because you can run you know all of the operating systems like quote legitimately you know meaning, meaning you're not hackintoshing it. And the company provides support for, Apple provides support for Windows

by the means of drivers specific to their hardware. So you kind of have it blessed, right? But here's the weird thing though, is that if you boot directly into Windows, if you have your Mac set to boot directly into Windows repeatedly, like, you know, anytime you turn it on, it's just going to go straight to Windows first, right? Then maybe you won't notice this the first time, but eventually what's going to happen is,

and I have no understanding as to why Apple would do this, but that hardware virtualization that Alan was referring to, when the EFI is booting up because it doesn't have BIOS on a Mac, but when the EFI is starting up on your Mac, it will opt for some reason to not start that virtualization if it's not booting into OS X or Mac OS. And so then you'll start up Windows

and your Docker client will start up and they're like starting Docker. And then it'll be like, oh, no, we failed because you don't have hardware virtualization enabled. You're like, what? Why? And there's the only consistent way that I have found that works, the tried and true way that works every time is to shut back down into the Mac OS or OS 10, and then immediately just shut back down and go back into Windows. And the simple act of booting it from a cold boot into Mac OS or OS 10 will enable

the hardware virtualization so that the next time you reboot, I guess at that point it'd be a soft boot, back into Windows, then the hardware virtualization is left on. And I haven't even found a pattern as to how long it's left on. Because sometimes it'll be on, like, I could shut down my Windows instance again and it'll still be on. Other times, you know, if I sneeze, it's like, nope, turned back off. Yeah, it's frustrating. And the whole layers thing, you reminded me of why that even came up

and why it was a pain is I used to run macOS and then I would have Windows run in like Parallels or VMware. Well, that's great. But if you try and run Docker inside your virtualized Windows, guess what? You can't do it. This is funny. So one of the reasons we've always recommended MacBook Pros for developers is because it's like the one machine that can do everything, right? You can do Windows, you can do Mac, and you can do Linux, right? Oh, how the mighty have fallen. It's weird because if you find yourself getting heavy into the Docker world, Microsoft has been doing amazing things in the whole container space.

And now like Windows 10 Pro running Docker, I can truly run a Windows container right beside a Linux container. You can do it. If you turn on the experimental feature right now, currently. Yeah. We talked about this a couple of times. Little cow.

Yeah. So I've actually turned this on and I've done it. You can run a Windows container right beside a Linux container. You can't do that with Mac OS because it doesn't support Windows containers, right? So it's like we're almost sort of, if you get heavy into the Docker world

or the container world, like Windows is actually right now better. Yeah. It's for that purpose anyways. Well, I wanted to point out too, these things are so squirrely. We just talked about how containers are different from virtual machines,

and now we're talking about running an operating system inside a container. It's crazy. And it is valid too. That is true. That is the advantage of running containers is that it's much smaller than VM. Oh, but you can run Ubuntu. So for example, the Python stuff I've been playing with is based on an Ubuntu image.

So I'm spinning up Ubuntu and it spins up whether it's on my MacBook or my Windows desktop, depending on where I'm developing. And what's nice is if I decide, you know what, Ubuntu's driving me nuts, I'm switching to CentOS. I do that and that's the only change.

It's a text change. Isn't that crazy to think changing your operating system can be such a minor tweak? Oh, it's amazing, dude. And even if you want to go crazy, so you can go into optimizations and you can be like, look, I don't want the 300 meg Ubuntu image. I want Alpine.

That's five megs. And guess what? It'll run almost everything, right? Like raspberry pie, like almost everything. But to Joe's point there, though, historically with containers, and kind of to the point you were making, Alan, is that historically it used to be that any container that you would want to, let me say any image that you would want to,

let me say, any image that you would want to run into a container had to match the host OS because it was sharing those resources or it is sharing those resources, right? It's only in, Windows is the only platform that I'm aware of where you can do other operating systems like Linux and Windows because they're the only one that I'm aware of where you can do other operating systems like Linux and Windows. Well, because they're the only one that does Windows. And the cool part is the whole reason why that even happened is because of Azure. If you really

want to boil it down to the nuts and bolts, Azure said, you know what, if we want to compete and we want to be up here with the moneymakers doing this cloud thing, we're going to have to make Linux work on our systems, right? Because that's what everybody's going to use in the cloud because it's cheaper, they spin up faster, there's not as much overhead. Dude, we are literally getting the trickle-down effect of them pushing Azure on everything.

And so we're getting the benefits all the way down to our development machines now. So I don't know that we said it, but the feature that you were referring to, even if you were to go into your Windows 10 and you turned on Docker and you switched to Windows containers, it'll immediately bring up a prompt saying,

hey, or at least the latest versions will, hey, do you want to turn on this feature? And the feature is called Linux containers on Windows, but I really want little cow to stick. So I'm saying it again. So that we can nickname that little cow. That's awesome.

And the cool part is all you got to do to spin it up is you say platform equal Linux when you're going to do this. It gosh it's so beautiful anyways all right i digress like i don't know how it is nowadays but it used to be that linux hosting was always so much cheaper so it's nice if like hey you want to develop on on windows but then deploy the linux like here's a pretty easy way of kind of testing that out and make sure it's going to work. And if it works in that container, it's going to work. Yeah, you're almost guaranteed. So we're going to take a quick break here and

do our fun stuff. But when we come back, we're going to be talking more about Docker and specifically what that means for developers. Yep. So we do it every time. It's my turn to beg. So, you know, if you haven't already, please do take the time to leave us a review.

We have a link to make it fairly easy. So all you got to do is go to codingblocks.net slash review, and we'll have links to Stitcher, which you don't have to sign up for. We have iTunes in there. So if you're on an iOS device or Windows, and please do. We truly read them all.

We take the feedback to heart. You'll notice that our news sections are shorter. You know, like we truly care about this. So, you know, please do it. It puts a smile on our face. It helps us. And, you know, it's your way of giving back. So thank you for all that have done it and for all of you who are now going to consider doing it.

And with that, we head into my favorite portion of the show. Survey says... All right. So last episode, we asked, how important is Docker? And your choices are... Very. Docker is the new git.

Containers are awesome, but Docker itself? Or, nah, this is just a stepping stone to something much bigger. And lastly, nope, I build and deploy from a laptop. All right, I think we went Joe first last time. So, Alan, you're up. So, I'm truly just basing this off how little I hear about Docker in our Slack channels. So

I'm going to say nope, I build and deploy from a laptop and I'm going to go with 40%. Wow. That's tough. I have a slightly different experience, but that's probably because I'm in there mucking around with Docker and very vocal about my frustrations with some of the stupid things I've run into, which have pretty much all been my fault, by the way.

But I've gotten to talk to some people about it, and so I think that it's more prominent. Oh, jeez. I'm going to say nope, I build and deploy from laptop still. Don't go with a dollar? I'm going to say 35. Oh. Alright. So, Alan with nope, I build

and deploy from a laptop at 40% and Joe is going to undercut him with the same answer at 35%. Right? I got those numbers right yep yep all right survey says you're both wrong oh come on right surprisingly very docker is the new git was most popular choice i am shocked yeah i wrote an article titled that yeah i i was actually a little surprised with that too.

What was the percentage? 33. 33% of the respondents, that was their pick. Did we only have three people vote? No, but our audience is conflicted though, because the second answer, which wasn't too far behind it, was, no, this is just a stepping stone to something much bigger. Man, you know, I'm curious about that,

because honestly, I haven't seen anything bigger. Well, you know, it's funny. If you would have asked me 10, 12 years ago, or whatever, Git was kind of rising. When I thought about the future of source control, I've been like, you oh, it gets cool. It makes hard things easy. The syntax stinks, though.

It's not going to be that great. I mean, GitHub's nice, but this is definitely a stepping stone. I'm fully backing whatever comes next. Nothing really came next. It could be, though, that maybe the people that are saying something much bigger,

if they're thinking in terms of like Docker, the company, and the commands, they're like, well, there's other containers, right? Because the question wasn't generic, like how important are containers? It was how important is Docker? Right. So then you have like, well, maybe those people are like, well, the open container initiative is a bigger deal things like that right um so you know i mean i'll give them credit so this is fair this is where i'm curious though is if it weren't for the fact that there seems to be

such wholesale buy-in right like microsoft didn't say hey let me just go invest in the open container initiative or like they literally said all right we're all in on docker boom right right and that's pretty big you know it runs on basically every platform which is no other as far as i know too many other container things that do that that's just why i'm surprised like i haven't heard of anything else that really seems to be jumping. I mean, as Joe pointed out, though, this thing has been in existence for 39 years.

The concept has been in existence for 39 years, and it just keeps evolving into what we now talk about under this umbrella. Like, Docker is the Kleenex of containers. Yeah, it's the Nintendo video games, the Kleenex of containers. Yeah, totally. It's exactly what it is. Like that's what when you talk about containers, most time people in their mind are saying Docker.

Right. Or if you say Docker and you just mean a container. Yeah. Right. Yeah. But Kubernetes kind of came out and it's kind of winning the war, I'd say, between Kubernetes and Docker Swarm. It's currently, by a long margin, the orchestration platform of choice.

So that makes me think, well, somebody could make something else that kind of could slide into Kubernetes easily. Then all of a sudden, there could be some real competition here. That's true. That's true. Yeah. All right. Well, in keeping with our Docker theme, this episode survey is, do you use Docker in your current dev life? And your choices are,

yes, so I can install and blow away software on my own system while keeping it clean. Or yes, it's part of my build chain. Or yes, it's part of my production deployment. Or lastly, ain't nobody got time for that. So all of those yes answers are kind of building on top of one another. So if you're only using it to install new software

that you want to play with, or not software necessarily as in UI packages necessarily, but frameworks, packages that you want to play with, like the Blazor example that you gave, keep it clean. But if you want to use it as a part of your build chain, then you're kind of like building on top of those answers, right? Right, that would imply that you're using it locally

and in your build chain. Yeah. Yeah, but part of my production deployment means like, I don't know anything about it other than, you know, Sandra over there has got it working and it's pretty cool. Yeah. If you're like,

if you're stumbling on like, well, I don't know which one of these to answer, you know, like think of those as like whichever one, like think of those as like hierarchically, right? Like the production deployment one would be like the largest one,

but you know, maybe that's the only thing you use it for and you you don't use it locally. And you don't even, you're not even aware of it. So whatever, whatever one applies to you. This episode is sponsored by airbrake.io. When your website experiences an error, airbrake alerts you in real time and gives you all the details you need to fix the bug fast. Now I mentioned earlier that I set up airbrake on a front end website. It was so easy to do because they provide open source libraries for all major languages and platforms. This is particularly nice because they also have a 30 day free trial.

So you can get airbrake set up in minutes and see if it's right for you. If you use our magical link, then you get a discount. Right now, CodingBox listeners can try Airbrake free for 30 days, plus get 50% off the first three months on the startup plan. To get started, visit airbrake.io slash CodingBlocks. That's airbrake.io slash CodingBlocks. All right, so now we want to talk a little bit about what Docker or what containers can mean, and let's face it, what Docker means for developers. And specifically, I want to kind of focus on this notion of building inside a container,

because like we mentioned with the Blazor example, or I've been doing some stuff with Python, that's radically different versions depending on what I'm doing. It's really nice to be able to have your build environment inside a container. So you can play with Blazor and the preview during lunch and then go right back to being productive. Or if the boss says, hey, I need you to make a fix in

this old version, you say, okay, well, let me run this Docker Compose file instead of that one. And now, heck, I can have them both up at the same time and here I am comparing. Easy peasy. No IIS configurations, no weirdIS configurations no weird stuff no swapping connection strings like no changing branches right

it's just right there so we want to talk about things from that side and I think the biggest thing for me was realizing that I can spin up a whole architecture with one command with Docker Compose and I think Docker Compose is really what kind of opened my eyes to like oh this is really cool because when you start doing like

a docker tutorial or a course like the end product there if you're just focusing on the docker command is going to be like a docker run statement yep with a bunch of flags and you know what that's actually i feel like that's really almost a disservice. It's important to understand all the Docker commands. You will need them all. But I honestly feel like I went about doing things the absolute wrong way because I watched those same courses, right? And I read all these things that told you how to use Docker.

And then as soon as you get into a situation where you need two or three things depending on each other, just a simple.NET app, take for instance, right? You have your.NET thing that's going to spin up, but it needs a database server. You're like, oh man, well, I need to Docker run my database server and I need to Docker run this thing.

That's the wrong way to do it because it's way more complicated. If you have a Docker compose, it does it for you. It feels like magic. The first time you see it happen, you're like, oh man. Yeah, and all the courses, they kind of build up to this Docker run command. You set the dash P, you do the ports, you do the dash V,

you do the volume, you do the dash T for the name so you can get this up and you run it and then you try to run it again. Oh, and you have to go kill it. And so it's just this really awkward workflow. And like, I think anyone who spent like, say, four hours working with Docker hates it. And they're like, okay, this is great. I've got this really complex command that I run

in order to get this thing running. Like I could have done that, you know, in PowerShell or in Bash, like been just as miserable. Thanks, guys. Yeah, so to describe what he's talking about here, just to give you an example, right? Like you might have something that says docker run dash ITD dash dash name, name of my container dash, um, golly, dash P and then 1433

colon 1433 dash some other RM dash something else. And then you have the name of the actual image you want to run. And that's mind melting. Like I actually just gave you a somewhat valid command, right? And I know what those mean too. Like it's bad, but I know what flags mean. Right. And actually,

as you were saying that, I was like, wait, why would you combine those two? So, so here's the thing about that though. And, and I want to paint the picture of Docker compose only so that you'll get why we're saying it's so good. When you run Docker Compose, you say docker-compose up-d. Done. Magic happens. Your containers all spin up. They're talking on a virtual network switch with each other by host name and these things all just work right so

that's why if you get into the docker world understand the commands for docker but know that that is not the end game that is so you understand how to work with these things okay i'm i'm going to sound like an idiot but i really want to know the answer to this though and maybe and it could have just been like uh you maybe you didn't mean to say it but um you said you said itd right so it would be to run it interactively d would be to run it as a demon in the background right how does that work together so if it's detached but you're interactive because if you're interactive it takes you into it right there are some things that you have to run in interactive mode. Otherwise, it'll shut down as soon as it starts up. That's the best answer I can give you. Depending on how the image was created,

you'll need to run it in ITD or sometimes you'll see it DIT. I don't know that the order of the flags matter that much. Seems like sometimes they do. But if you have something that hooks into a particular interactive process and you don't put IT, even though you don't want it to attach to it, it'll shut down as soon as it starts up. As soon as it's finished cranking up, it'll turn off. Can you give us an example for those of us that are...

I want to say Alpine Linux might be one of those things that when you start it up, if you run it, or maybe even Ubuntu, I want to say Ubuntu, if you don't do ITD or DIT, then it'll turn off as soon as you do it. So what I was doing with the ITDs was basically I do the D, so it's a daemon, which just means it doesn't take over my terminal. I can run stuff like from there on, right? But the IT, well, I kind of think it was like, it pops me into that container so I can go ahead and run commands. And so sometimes I would just do that when I was working on things to be like, okay, now I'm in here.

Let me check and make sure that everything I copied is where I think it is. And it was just for debugging purposes. So that's why I kind of used IT just for kind of checking stuff out. So I haven't run anything where I needed to run it, but I've definitely done the ITD trick. And then what's nice is when I exit the session, right? So I log out as root, I'm back to my terminal

and the architecture is still running. Container. And I have control of my terminal, right? So I don't have to open up a new tab or whatever. Yeah. All right. You'll find out that there are containers. I've never ran that combination. I mean, like when you said it, I was like, well, I out that there are containers. I've never ran that combination.

I mean, like when you said it, I was like, well, I know what those are. Like Joe joked about like, I know what that command is that he just said. I was like, why would you do that? Yeah, I'll have to find one where they actually spell it out because it has to do with it not thinking that it's done. Yeah, I just haven't ran across that need yet. Well, I've got kind of an example that I saw. So I was working on a Flask website,

and the way Flask runs is it basically runs like Python, like Flask, and then a couple arguments, right? So if you have a syntax error, it's going to reload. It's going to crash Python. And now with Python crashed, there's nothing else to run after that. So if you don't have that I running, your container is dead. It shuts down. It's like, okay, I'm done. I read, I ran everything that you gave me to completion and now I'm done. I'm going home.

Interesting. Yeah. I don't know that the dash I would fix that. It would have been nice because that was a real headache for me. So the next bullet point you have here is changes are a bit trickier. What are you talking about? The Docker compose or, uh, yeah, a little bit of a combination.

So, um, so I drank the Kool-Aid and watched the courses. I was like, okay, great. Then, you know,

like when I use Docker, I know where that works on my machine kind of crap. Like it's going to work here in dev. It's going to work there in stage. It's going to work in production. It's all going to be the same. I'm going to pass the same logical unit, the same container. I'm going to ship it from one place to the other. It's going to work here in dev. It's going to work there in stage. It's going to work in production. It's all going to be the same. I'm going to pass the same logical unit, the same container.

I'm going to ship it from one place to the other. It's going to be great. I'm totally sold. I got my sample app here. Okay. And let me build. Well, let me build,

build. How do you, how do you build? I'm working in visual studio. I was trying to do a.net core app. I go up and do build and well, it's, I mean it built, but it's using the build on my machine. So I'm working in Visual Studio. I was trying to do a.NET Core app. I go up and do build, and well, it's, I mean, it built, but it's using the build on my machine because I'm running Visual Studio outside the container, right?

So it's building with whatever, and it didn't do the 2.1 preview. So it's like, okay, well, that's silly. I mean, what I need to happen is like a.NET build inside the container, but I don't want to have to shell into that container with the IT trick every time I want to run a build, right? That seems really stupid. So I was like, okay, I mapped, you know, I haven't volume mapped anyway, so that's a

big trick right there is just if you're getting started with Docker, like you almost always want your source code to be mapped to just a convenient drive on your computer. So when you do your Git and stuff like that, you don't have to keep doing that stuff in a shell. I'm going to say something. Sorry. So one trick just to be aware of, and this isn't

this is also something that you wouldn't necessarily want to do every time, right? You kind of want to work within Visual Studio if that's what your IDE is. One trick that a lot of people don't know about is you don't necessarily have to get into the shell of the container to run something. Like a Docker exec and then call whatever your container name is and then tell it the command you want to issue. Like an example

would be a.NET Core clean. If you want to clean everything, you could literally say Docker exec my container.NET Core clean. And that would actually exec it and then return you right back to your own command. So whether you're in PowerShell

or whatever. So that's one thing. I am curious though, what do you have? Four solutions and they all involve mapping volumes? Yeah, I came up with four. I did a lot of Googling trying to think because it just seemed like this seems like such a kind of obvious thing that would work. And so the solution I ended up going with on my dot net core project was my first solution here

which is just using technology that doesn't require building right so i ended up i got so sick of dealing with this problem and i i just hey it made me feel like an idiot i'm like i cannot understand like this is supposed to be so easy and so great and so brilliant and i'm so close to having this beautiful solution that just works how i want except i can't you know actually make changes so this isn't working out for me as developer and i'm an idiot so i was like you know i'm going to python and so that worked out anything you just that's what i thought language yeah that's what i thought and i don't know python very well but uh python is one of the languages you just gotta type whatever and like somehow it just works anyway like

like type in pseudo code and it works it's crazy and so it like worked for the first couple hours and so i was like this is brilliant i'm switching everything delete all my dotnet core like all right i'm in and then i i finally mistyped a comma or something and it had a compiler error and it crashed the python service inside the container. And that's how I knew that. Oh, if you get a bad enough error in Python, it'll end up crashing the Python EXE and then you're out. The container's dead.

So Python sucks now too, so you just switch back over to.NET Core, right? I deleted it. I think this is where you went to JavaScript. I thought about it. Exactly. No joke. Let me look at Express here. So I was like, okay, you know what?

This is like, I keep hearing about people specifically using Python. And a big reason behind that is like Python is really big with the versions. Like there's the version three people and the two, whatever, seven people. And like, they don't like each other. They do this whole like virtual end thing to kind of work around it because it's so crazy even on my mac like i've got two seven working but it's like this weird two seven version that doesn't work with pip and it's just like this whole big big mess just to work locally in fact like if you go like look at instructions for installing flask it's like all right if you're on windows it's this wiki if you're on mac it's this wiki if you're on and it's

like man no that's not, this is what we're avoiding. This is the whole value proposition of Docker. So if I can't get this working as a developer, then I'm skeptical about the whole premise. I kind of feel like so many people are so pro-Docker that I must be just doing this wrong.

So I talked to some really smart people about it. Big thanks to MadVikingGod and talked to the people. I'm sorry if I'm leaving about it. Big thanks to Madviken God and Dr. Elickman and a few other people. I'm sorry if I'm leaving you out. My buddy Kirk Allen, Dr. Allen read a bit about how they acted on this. And so I came up with these four solutions. One was just use a technology that doesn't require building. So switching to Python, that's a crappy answer, but it works.

Number two, this is what I really wanted to do. Set up a watcher, which is a process. You've probably seen it before. It's really common in JavaScript nowadays. It's a process that kind of watches files and it looks for timestamp changes. And it's like, oh, okay, a file changed. Now I'm going to trigger a rebuild.

And so you set up that watcher in the Docker container. And it knows when things change and the build happens there. And hopefully, you know, it doesn't crash because then, I don't know. I don't know what happens if the... Well, I guess it doesn't see if timestamps... So it's like an infinite loop. That's what I was kind of scared of,

but I don't think that's a problem. Anyway, idea is set up a watcher. And I could not, for the life of me, get the.NET watch working in the 2.1 preview. And I know they made some changes to it. They actually kind of built it into.NET. It used to be like a kind of a third-party plugin I know they made some changes to it. They actually kind of built it into.NET. It used to be like a kind of a third-party plugin. So they made some changes there.

I could not get it working in Docker for Windows with 2.1.NET Watch. But that, I think, is a great solution. The third was, like Alan mentioned, basically running the command inside the container. You either do like Docker exec or you keep that active terminal up IT. So you're just in there and you just run.NET build in there.

Or you know, Java or like whatever build process you've got. Now, here's what MadViking gave me, right? He said, why don't you just kill the container? Like, well, I don't want to freaking download my operating system. I don't want to download 2.1. i don't want to freaking download my operating system i don't

want to download you know 2.1 i don't want to like rebuild my image every time that's crazy no no no that's not how docker works is this notion of like read layers and read write layers and finding file systems all sorts of stuff and we're not going to get into it just too much but what it means for you is that it's only going to do the very tippy top of that cake. So when you kill that app container, you spin it back up again, it's only going to do that build.

And it happens in like two nanoseconds. I can imagine if you've got a bigger build process, like if you've got to build a big project that takes, you know, say 70 seconds for a full rebuild, then I don't know how well this is going to work for you. That would be pretty annoying when you need to build this one thing to rebuild the whole architecture. So I'm sure there's still a better way. There's probably a fifth solution that I'm just not thinking of, or maybe you just

get more advanced with your Docker setup and the watchers. Okay. So I'm trying to follow along here. If I understand what you were saying, then what you were, where you were starting with it is you wanted to have a, you wanted to create a Docker image that you could run a container that would remain running and it would do your building for you, but, or as needed, ideally, maybe, but you only intended to have to start that container, run that container one time and just leave it running. Well, I thought I'd be able to just build Visual Studio. That was like, I wanted to continue my normal dev flow.

So he wanted to be able to write something in Visual Studio, hit save, hit build, and then be able to go to the web browser and see the changes. Versus the flip side of that would be, let's pretend, let's take Visual Studio out of the equation for a moment. Pretend that you were using MSBuild to do your compilation, right?

So what you were trying to avoid was going back to the command line to rerun whatever the command might be, be it MSBuild, blah, blah, blah, or Docker run, blah, blah, blah. You were trying to avoid rerunning that thing each time with it having the express intent of, hey, I'm going to spin up, load up some files,

compile them, and then save out the output and shut back down. Like that's what you're trying to avoid but that's where that's where you ended with number four right yeah so i i end up killing it of a blur of that then right it was just faster so with the docker exec thing it kind of meant keeping a second thing and kind of in my clipboard so i've got like docker compose up to start everything and now i need a well i guess it's more than two then i need a separate command to a second thing and kind of in my clipboard. So I've got like Docker compose up to start everything. And now I need a set.

Well, I guess it's more than two. Then I need a separate command to kill that image or not. Sorry. I'm sorry. I got mixed up. So now I need two commands, right? So I do Docker compose up,

everything spun up. And then I say, um, wait, Docker exec. And then the build command. So I've got these two things that I've got to kind of keep in my clipboard. I've got to keep bouncing between.

Wait, what was the Docker Compose up doing? What was it? It just spins up the whole architecture. So I've got like say MongoDB in there and.NET Core or whatever. I can spin all those guys up. That's the runtime though, not the compilation of it there, right? Right. So yeah, I'm definitely

mixing my concerns here. Yeah. Yeah. Yeah. Okay. So that's what I want to make clear is we're confusing things. Cause that Docker compose up was to spin up the running architecture to actually like use this thing.

But the compilation of it could just be a simple Docker run command. Yeah, I guess you're right. Like now that I've like, I've gotten to the solution that I actually like, and it's really not that different from what i was trying to avoid in the first place the act of building the thing is just the docker run command the act of running the thing though is the docker compose up those are different use cases no no so so docker compose up is the same

thing as Docker Run. But no, no, no. What I'm saying is in his use case, what he's doing, he doesn't need a running instance of MongoDB in order to compile his C Sharp. So he was Docker Compose Up in order to spin up several things like a web server, a database server, things like that. And what I'm saying is, no, no, no, let's boil this down to the root problem here which was just a docker

run command oh so so i know the use case that he was talking about and i think this might be why it's confusing so he talked about his python crashing right and the problem that he had was well doggone it what do i do now i don't want to have to do a docker compose down because that's going to break down everything that was running. So if he had three servers running, Python, Mongo, whatever else, that's going to take it all down. Then you're going to have to run Docker compose up dash D again,

and then it'll spin everything back up. And that seemed like a big waste. What he was getting at here on number four with the kill the app container is Python crashed. You can literally say Docker RM dash F and then whatever that Python container was, then you can run Docker compose up again and it will only start up what is

missing. Oh, is that what you're okay? That's where he was going with that. Now that said to answer, to go back to the building, there is a watch on.net on the.net stuff to where when you run the build thing, there is a watch on.NET, on the.NET stuff to where when you run the actual container,

it'll be something like Docker run, you know, my container, and then based off the.NET core thing. And then there's a, I think it's called run watch or something like that. It's a parameter that you can pass to it that is made for developers that literally as you change the code,

it will automatically behind the scenes, there's a file watcher inside the container that will look for change files in your source because you'll have mapped your local source volume to the container and as you change those files it's going to recompile it and then that way when you go back to your browser you hit refresh you don't have to do what he said he was having a, he was annoyed with, which I would be too. If every time I make a change, I got to go back over to the terminal and say, all right,.NET Core compile. I would be like, okay, I don't want to do this. But it actually has a command that you can tag on to the end of that Docker run

that will allow it to sit there and watch the file system and recompile for you on the fly. Yeah, I mean, I could not get that working though. I did last night, actually. So I couldn't get it working in the preview, I should say. Mine you on the fly. I could not get that working though. I did last night actually. So I couldn't get it working in the preview I should say. I want to see what you did because I tried setting it as an environment variable which is one option.

I tried setting it like the actual.NET command. I tried setting it and then I tried a couple of the weird things too. So I'll give you a hint. One hint. If you do that, download the preview, install the sample application, which was a Git pull, and I'd have to find it. I was looking for it a second ago, and I didn't find it.

But if you pull down the samples, it worked perfect. So literally, you could basically just get it in there and then blow away that source. Because I downloaded the Git to my computer. I mapped that volume or that folder to a volume in the container. And it worked beautifully. Like literally, I go in and change a file and it would be up there. You know, I'd go hit refresh and it was there.

I got a hard error. I couldn't even load the site when I tried to do the watcher. It gave me this like loopback IPv6 error. And so I tried all sorts of stuff. But yeah, I'd love to see what you did. Maybe it's not an issue. Maybe I can go back to.NET Core. Yeah, somebody actually asked this question in Slack stuff, but yeah, I'd love to see what you did. Maybe like, maybe it's not an issue. Maybe I can go back to.NET Core. Yeah.

Somebody actually asked this question in Slack about, you know, how can I do Blazor? And I was like, oh, the best way is to run it in containers. I have no idea. So I'm, I, I hate to promise this kind of stuff. Cause I don't, you know, I mean, timelines. Yeah. Here it comes. But I plan on getting together a YouTube video of literally, Hey, you want to get going

and play with the preview. This is how you do it, right? Like I'll show you how to set up the container. I'm probably not going to go into all the little bits and pieces of it because I mean, we've been talking just about random pieces here and we're an hour plus in. Um, but I do want to get it to where I can say, Hey, you want to play a Blazor? This is how you can do it. Boom. Here's your container. Here's your thing. Go run it. Well, the reason why I took us on this tangent to begin with, though, is because I guess Docker means something different. Containers mean something different to every person, right? And so the use case that I have been thinking of that's near and dear to my heart is,

well, from the build infrastructure, I like the idea of baking in my version dependencies for compilers and frameworks and things like that into an image. Then I can be like, hey, Mr. Build Server, here's the image. When you need to compile this thing,

you pull down that image and go compile it. But this other version can pull down a different image version to compile and see, you know, so, but I'm not thinking of Docker compose in those situations. Right.

And that's why I was getting kind of tripped up on your explanation there. So I understand it now. I appreciate that. Um, that, that breakdown. Hey, I will say to,

before we move on completely, cause now we're just in tangent land anyways. Yeah. Tangent land. Oh, are we always? We are. Hopefully useful tangents.

But what you just brought up that I think is so key that I didn't even know existed was you said you're thinking about it in a DevOps type of way, right? Not just a developer way. And one of the interesting things that I never knew about until I watched some presentation at, I think, our Atlanta Code Camp, I, too, gave an amazing thing. But using it for checking your tests.

Yeah, running unit tests. Running unit tests. And one of the cool use cases was, okay, the code for your unit tests get deployed to the container where.NET Core is also running. And the way that he would do this thing is he would basically call the.NET Core and then whatever the run testing was.

And if the container exited properly with a zero, then everything was good. But if the container failed and returned back another code on the test, then you knew it blew up. And so you could actually have that in a build pipeline is like, yo, if this thing exited

properly, hey, everything's good. If not, fail the build, do not deploy, do not do whatever. So it's another use case that I would have never thought of because I'm not in the DevOps world. Well, the reason why I really like it though, is not only from a unit test point of view, but if you were to think about this from like, if you, the word ephemeral was mentioned earlier, right? So like, if you were to think of the box running that container or that image, um, it has a running container on it as ephemeral itself, and you don't want to have to have to install anything other than Docker on it. Right. But yet you might want to have several build agents running on it, or you might want to be able to spin up build agents in your cloud provider,

right, and just say like, hey, anytime I want to build, do a build, this is the image you need to pull down. Like in my mind, that's where I kind of get excited about it, right? Like, or, you know, versus some of the other use cases, right? It's like the ability to parallelize and distribute the build process consistently with all those dependencies baked in. That's really exciting. Let me tell you where I ended up.

I think those will kind of help. I didn't do a good job setting this stuff up. Explain it's hard, man. Where I ended up with this thing python uh i've got a python website i've got an elastic search um search engine and i've got cabana which is like an admin site so i've got three containers working in a compose file they're all on a shared network they can all talk to each other everything works great now i i type in docker up, it spins up all three.

And if Python crashes, the other twos are still running, so I run Docker Compose up, and it automatically pops the one in. What I could have done there in the.NET core application is basically done the same thing, except if I needed to kill that box and rebuild it, or kill the container and rebuild it,

I would have basically done something like a Docker kill website and Docker compose up. So it wouldn't have been terrible. And I realize now that that's really not that different from doing the Docker exact thing to just run my build that way. For some reason that just seems cleaner to me.

So I like just being able to hit up on the keyboard, though. Docker Compose up, and there it is. It is sweet. So we've talked a little bit already about why you should care if you're not working at Google, and we gave an example of what a workflow could work like, although I mostly focused on the problem I ran into and not the benefit,

which is running Docker Compose up and everything just being great. But some other kind of benefits that we came up with is basically simplify onboarding. So if you've ever worked anywhere that had like a wiki for how to set up your dev machine, then this is a significant way of reducing that cost. What about also simplifying, like if you're trying to move your entire team

to a new version of a tool or a framework, if you wanted to, because that's still kind of like an onboarding, but it's an ongoing onboarding for existing team members, right? Like you're still simplifying that. Yeah, how do you do it now? Like you send an email, say like,

everybody, we're going to 4.7 next week on Monday at 5 p.m. Right. Like hopefully you don't have to work on any legacy stuff. Ever. Yeah. So, you know, that's really nice. And I recognize that's a one-time cost.

And that's kind of like some of the pushback I've gotten when I've talked to people that aren't working in a Docker environment now. I'm like, it simplifies onboarding. And they're like, okay, so that's day one of my 3,000 days I'm working at this company. You know, whoop-dee-doo-dah. But that's not necessarily just day one, right? It can be day 100 when you decide to upgrade to a full version.

Or you get a new computer or you start working on a new product. Because one thing that's kind of funny about, say you start up a new service or a new application or a new library, it's really easy to just kind of toss it in the current solution because I don't have to add any automation. I don't have to spin up a new whatever. I don't have to create a new repo. It's just easier to kind of stick it in there.

But I think in the Docker world, it lowers that barrier to innovation, another one of those phrases, those marketing phrases that slipped into everything. I do think it makes some things a little bit easier to kind of componentize and move things around. So if you did want to say go microservices route or something like that, then I think

that this kind of opens some of those doors and makes some of those options easier to take. And man, tool version problems, maybe they don't happen that often if you're working in a small team, but when they do it's really annoying huh you ever have like say for example bauer mysteriously not installing something for you or just hanging for 20 seconds you know i feel like you did that on purpose yeah jerk uh eliminating app conflicts i mentioned the registry thing before

that used to be a problem you have the old one and the new one and some old timer there tells you what the trick is, you install the new one and then the old one and then you go back and change these three flags and then you just have to change those three flags and then restart your computer, like oh thanks

sounds terrible so it makes switching branches like you know turning the mayflower uh it's pretty cool to be able to download isolated versions of your entire architecture so if you do need to spin something up it's nice to be able to do that and like you know of course like that that's one of those things that sounds great on paper it's kind of hard when you've got like a big honking database it's like full of like seeded data that you need to deal with and so this is not definitely

a silver bullet. There are no silver bullets. Docker is not going to revolutionize. I feel like databases mess up all of our conversations in this regard. Yeah. It's the data of it that messes up the conversation. It's like, well, I don't want to redo

all my data. I will give a cool use case for Docker. So, you know, at our job, our day job, we have, you know, versions of our database that we ship. And one of the things is we need to run some tools against this database and it can mess up data. And that puts you in a bad state. And what do you want to do?

Do you want to back up your database before you do this and then have that sitting out there and then restore it every time? That's a pain. I actually was able to take my database, plop it into a container, and basically I can just run our database version XXX, and boom, I've got an up and running thing that I can literally blow away, start over, I'm back in the same exact

starting state that I did. And this is actually a way that you could do integration tests and other things as well, right? But it is nice to know that you can do something like that. Yeah, we mentioned like this ephemeral nature of Docker containers because you spin them up and

you kill them like you can totally you know demolish them right and that's great but um you know the question is like well what about persistence what about the things that i want to stay the same and there's solutions for that too and we didn't dive into details but it's basically you map volumes to like some sort of shared location so some place that will be shared between instances so when you spin it up and it is something that you configure um like when you run it and so you know when we said that thing about the docker run command and all the different flags and stuff the reason you have to pass all those flags is because that's something that you can run run again and run again and can kind of compose like these little lego pieces and so much of this stuff ties back into what we talked about back in

the 12 vector app i mean every little bit of that, it seems like the container-old DevOps world really took a long look at that and said, you know what, let's go with that, and here we are. Yeah, stateless being the key part, right? For the most part, that's what you want. I still look back at that. I'm so glad we covered that 12-factor app.

Oh, there were a lot of great takeaways. I loved that series. If you haven't listened to that, you should definitely go back in our back catalog and look for the 12-factor app episodes. There's only like three, maybe four. Even recently, I was talking to somebody about the 12-factor app and I was talking about how 12-factor

recommended environment variables. They just thought it was crazy. I was like, I remember that there's really compelling reasons to use environment variables and they just thought it was crazy and I was like, you know what, I remember that there's really compelling reasons to use environment variables over config files and I had to go look it up because I had forgotten. But now after working with Docker, I'm like, oh god, I don't want to put the stuff over the config

file because now I've got two containers with that same config file in it with the same values and now they're both trying to run on the same port or whatever. I really need to have this stuff outside of the source control. And that's the kind of stuff that I can have on a map drive and a map volume that specifies those settings in one spot

and load those guys into the environment variables. And now I've got the source code, the same exact source code in two different spots, but it's running with different settings. And I don't have to worry about a shared application database or anything like messing with that. That's kind of a hard problem to solve

if you don't go the environment variable path. Yep. Could even be something that you don't want saved into a file. Yep. And your logs are a great example of, we kind of talked about using map drives to kind of get stuff into the container, but you could also have that container

right to a map volume inside that writes your log somewhere more convenient, like your desktop. Just a heads up, I do want to note so nobody goes into Docker just headlong without doing any research. The environment variables in Docker, when you pass them in,

you can look at them. So it's typically not a great way to pass in a username and password because you can just do a Docker inspect,'s typically not a great way to pass in a username and password because you can just do a Docker inspect, inspect the container that's running and see the username and password. If you lock down the system, fine, whatever, but just be aware, environment variables

aren't exactly the same as true system level environment variables. Yeah, so like one way I would like to think about it, I'm sure there are better solutions for more bigger-scale stuff like the Googles or whatever the world. But one way to get around that is say, okay, in my production, say my production AMIs or my production images that I'm spinning up in the cloud, there is a file in there

that's got my production credentials in it. And so now when I deploy it... Kubernetes handles that stuff, so it's not a swarm. Yeah, it just sort of takes care of it. You don't even have to think, Kubernetes handles that stuff. Yeah. Swarm. Yeah. Yeah. It just sort of takes care of it. You don't even have to think like, why are you trying to invent solutions? This problem,

like encryption security is hard. Like if you can get a tool to do it for you, then there you go. And that might be the reason for you to actually take the step into Kubernetes. If you start looking at doing this in any kind of real type environment. So. Well,

I was thinking of examples like with um visual studio team services though where going back to my build um pipeline example like it'll team services you can pass tokens as environment variables so uh i don't know i think those though are like one-time use or you know short-lived like now i'm going to go back and check i'm curious to see how like how team services handles that but that's the example and that is for like you know an authentication kind of purpose but you know it's a very special short-lived it's not you would you know specifically like if you wanted to be able to access a private nuget feed for example that's also hosted by Team Services, you need them

to pass that authentication token to you so that your code can have access. Your script, your build script, can have access to that feed. That makes sense. Again, going back into the workflow of using things for build purposes. Cool.

As a high level, why should you care if you're not working in Google? We're talking about simplifying, increasing your predictability and protecting your consistency. I want to add one more that's not in this list and I hate it that I'm interrupting you here.

But when you have containers, all these cloud things now, AWS, Azure, all those, if you got this thing deploying on yours or somewhere on staging or production or whatever, these things also now can just be run directly in the cloud. So Azure has Azure container services. I'm sure AWS has something very similar to the equivalent.

I know that Google does. So you literally have these things that you can bundle up and just automatically say, hey, run this. I want you to run this thing and it knows how to use it because it can leverage containers. Yeah, so you do this stuff to simplify your dev life, but now all of a sudden you've bought a ticket to Kubernetes or to cloud or to whatever. You've been simplifying your CI pipeline because you've bought a ticket to kubernetes or to cloud or to whatever like even simplifying your ci pipeline because you've standardized and simplified your deliverable now all this other

stuff has suddenly become easier like devops continuous deployment integration cloud yada yada that's huge so another way of saying that it's like production meaning that now you've kept your uh you know you're adhering better to the 12-factor app because you're keeping your dev and production environments at parity. Yep. Yeah, and so I also want to mention, if you are into this sort of thing, Docker and stuff, you should come to the Slack and hang out

because I've been kind of whining about it and bashing my head against the wall and also having some breakthroughs in the Slack on the weekends. So I'm coming to hang out. I thought it'd be fun to do a little lightning round. I got a couple of questions here we can zip through. Not that we ever zip through anything, but whatever. What are you saying?

So we talked about the poll, but we didn't really say what our opinions were. So what do you guys think? Is Docker the new Git? Yes. All right, Outlaw? Man, is it? I know you love Git. It's definitely got...

I want to agree just from the buzzwordiness of it, if that makes sense. Look, I don't want to say that it's not going to go the way of what was the old place that used to be the SourceForge. I'm not going to say that it's not going to get leapfrogged at some point, but for the very near future,

next three to five years, I think Docker is the new git. Yep, I think you're going to hear that Docker a lot more often. Okay. How deep do quote unquote normal devs need to go with containers and Docker? Normal devs. Yeah, I know that's a terrible question, but let's say like, I'm not a dev who is generally concerned with my DevOps pipeline.

I have the checkboxes, I create web services. How much do I need to know about Docker? I'm going to say, I think just like Git, it's going to be expected that your knowledge of it is going to grow, right, I think. Like in the beginning, maybe somebody's going to be expected that you're going to your your knowledge of it is going to grow right i think like in the beginning maybe somebody's going to figure it out figure out your specific environment be like okay i've added this docker file into the repo and anytime you want to use it you just need to do a docker run or a docker compose up or whatever the case may be

but then over time you're going to be, you're going to get more hooked into it and you're going to be like, oh yeah, okay, this is a specific thing. I can't just rely on Alan to fix the problem. Does that make sense? Yeah, I'm kind of, I'm there. I think that normal devs need to be

at least comfortable enough with it to be able to try out a new version of a technology. So if you're a Node developer or something, right, and Node 7 comes out, is it going to break my app? You know, rather than trying to get your entire system set up to where you can switch between them somehow, you should be able to say,

okay, let me put the next version of Node in a container. Let me put my source in there and see what happens. I think that it's going to be at least that. I think it should be at least that level of involvement. What about junior devs? Like if you're just graduating college, you know you need to learn Git because no one wants to teach you Git on the job, right? They want you to know it. What about Docker? Is it our jobs going to expect you to be familiar with Docker as a junior developer?

I don't think yet. It depends on where you go, but I don't think yet. I don't think so. Yeah, I'm with you guys. Maybe maybe, you know, Docker run. I think you should get involved with it if you're a junior dev. Take a look at it, right? Like see how this is, why

this is important if we haven't convinced you already. Well, I mean, like, when you say Docker for junior developers, I'm like, I'm assuming you mean like, hey, I need you to go create this, you know, I need you to create a Docker file or, you know, like that kind of thing. Like, I don't think that's going to be expected.

Basic commands, like, hey, I'm going to tell you this command and I'm expecting I only have to tell you once, like Docker run and it's going to be like, okay, like, hey, I'm going to tell you this command and I'm expecting I only have to tell you once like docker run and it's going to be like, okay, yeah, I can do that. Yeah, I agree. Yeah, totally. Oh, I like this question. When is it the appropriate time to introduce

docker? Because you know, with like unit testing, like it's in the beginning or not at all, basically, right? So is there like a cutoff point where you'd be like, you know, we want to dockerize but, you know, it's just too hard now. I don't think there's ever a late. Nah, I think. I don't think so either. I think it's just like anything else you iterate. If there's a place that you can introduce it and it helps, go for it. Yeah, I mean, I don't think it's going to be

a one size fit. I don't think it's going to fit everybody's situation, but if you think that it can,. I don't think it's going to fit everybody's situation, but if you think that it can, then I don't think there's ever a too late. Right. Yeah, and that's rarely the case. You can imagine you're working in.NET land and Entity Framework comes out and you've been using something totally different before.

The chances you slip into that legacy product are not so good. But Docker... Yeah, I think it's valuable. I do want to share this. Speaking of that whole thing, the whole iteration approach to it, like doing parts of it, I was just listening to the Six Figure Dev

with Julie Lerman, and they asked her a really interesting question on Entity Framework. Like, hey, should we switch from EF6 to EF Core 2? I think it's 2 now that's out. And she's like, no, that's the wrong approach. If there's a piece of it that you can benefit from switching, then do that piece. Don't try and wholesale do it. And I think that same approach fits here. If there's a piece of your application that you could Dockerize or a piece of the workflow that you could Dockerize, you know, try it out, but you know, it doesn't

have to be an all in type thing. And that kind of leads us to the next question is like, you know, when should you just not mess with Docker? When is it not appropriate? When should you not mess with it? I don't have a good answer like i i feel like i think yeah i i feel like just about everything with technology is time appropriate you know so i i i think that's a bad question i personally I think that you should always at least take a look at it and see how it can help you out in what you do. Yeah. The only thing I can really think of is like, well, you know,

if I'm not working on a website, maybe I'm doing, you know, embedded and it's just not available. But even then, like, I think it's pretty nice to have your build tools in there, although it can be a little quirky to get that build working. Yeah, you may not deploy the application that way, but it might be nice to have your builds in there so it's toss-away stuff, right? Yeah.

Yeah, what about front-end devs? Like if you don't have, you've never talked to the database, you're just, you know, you Angular all day, all night. Dude, no, that's perfect for it. It's absolutely perfect because you can literally spin up multiple versions of Bootstrap or Angular or whatever and literally have, see what happens. I will say one place where it's a little frustrating is like I mentioned the database thing that I did earlier.

And the problem is when you have a database with any amount of data in it, if you want to be able to blow it away and redo it, then you've either got to copy your database files into the container at the time that you started up, or you need to have it just be a part of that container anyways, like you kind of baked it into a layer. And those things can get large, right? Like you end up with a 20 gigabyte, you know, container file. So that seems kind of wrong. Maybe that's not a great use of it because it's pretty resource intensive on your computer. So maybe that's not the best use of it.

But outside of that, I can't think of a great reason. I was thinking about when it's not appropriate, it's like heavy UI. Yeah, I agree. If you're an iOS developer, I don't think it's going to help you. I agree. Okay, that's a good point. It goes back to the whole, you're not going to run

Firefox in it. It doesn't make sense. I mean, and like you said earlier, people are going to be like, well, you can. Okay, doesn't mean you should. I can totally cut a steak with a butter knife, but it's not really what I want to do. Right.

I want a steak though a butter knife, but it's not really what I want to do, right? Right. I want a steak, though. Thanks, Alan. Yeah, sorry. So we talked about the marketing and kind of like the buzzwordiness of Docker. So what do you guys think? Do you think it lives up to the hype

or do you think there's some rough edges there that they kind of hide beneath the whale? You go first. Yeah, I definitely think there's some rough edges. I don't know who that you was. I'm sorry. I was absolutely going to say Rough Edges. I think it totally lives up to the hype with the

same caveat that all technology has, right? It all solves a problem, but there are more problems to come along with it, right? You introduce a new stack, you're going to run into some headaches. And I think that you're going to have have that here but it solves so many problems that maybe the headaches are worth it but you know i you know and one thing i don't even think we got into though is like i mean it does create other issues though like you you put together an image that has all of your dependencies in it. And then you find like,

Oh, Hey, there's now a new security flaw that was found in that. And you need to update everything. Right. Like now it's like, Oh, well you got to update the images for it.

Right. Like it's not, it's not the same as just let me install a patch on this OS to fix this now. Right. Right. But the cool part is though, you can take that image me install a patch on this OS to fix this now. Right. Right. But the cool part is, though, you can take that image and install the patch on top of it. It's just another layer. Right.

Now you use the new image. And the other thing that's cool, too, is with something like Kubernetes or Swarm, whatever, like if you've got 30 boxes out there running and you need to start patching them, like you can just go ahead and kill a box, take it out. Now there's 29. And it's in charge of like orchestrating and kind of balancing that stuff based on your declarative needs and you can upgrade those guys. And so you can just start taking the boxes out and pushing them back up and like seemingly

everything's stateless and you've got a good setup. Like it should just work. Yeah, it's interesting. Now I will say where one thing where it is a little painful is you have to have the right environment to do this stuff. So let's say that you're doing awesome as a developer. You got Windows 10 Pro or you got your Mac or you got a Linux box and you're doing all this stuff. Now you want to deploy the thing.

Oh, well, we don't have a production. You know, we don't have Windows Server 2016. We can't actually deploy this thing. Oh, well, that kind of stinks, right? So you do kind of have to be aware of, you know, you might have this pie in the sky thing, but you're running Windows Server 2012 R2. Sorry, you know,

not happening. Well, I guess kind of where I was thinking with the security example, though, is it's easy for those those dependencies, what would they be in this case? Flaws? No. Holes? Whatever. Something. I need words here. Yeah. Whatever that word would be. It's easy for those

risks to remain hidden, right? In those containers or those images without you realizing you know, like a new CD comes out, for example, you might not remember like, oh yeah, there's this Docker file I got to go. That's, you know, calling in that version. I got to go update that, right? Like it kind of makes it a little bit easier.

To forget about. To forget about it. Yeah. Maybe, maybe. It's interesting because I'll go back to the whole patching the OS reduces the attack surface.

So that's probably more important because Docker containers run in silos within the OS pretty tightly depending on what you've opened up, port you allow in, and all that kind of stuff.

So your attack surface is a lot smaller, but it is true. You can have a ton of them out there that you just don't ever pay attention to. It depends on what kind of attack surface you're concerned about, though. Like, your attack surface could just be unknowingly you were a contributor to a DDoS attack.

Or, you know, because maybe you're a reflection endpoint because you're the version of in-map that you're running and you didn't even realize that you had it exposed or something like maybe you wouldn't run in-map in a docker container but you know that's right as an example where i'm going with this right like you could be part of a larger attack unbeknownst to you yeah it's or even like you know uh the you, if you baked in your web server into it, into your container or your image rather, and then, you know,

now you find out that it's using a version of SSL that's susceptible to the next heartbleed, right? Or whatever, right? So. Yeah, it's a tough one. I think that you still have the concerns like you have to pay attention to it. Yeah, that's true. Yeah, I mean it's a tough one. I think that you still have the concerns, like you have to pay attention to it.

Yeah, that's true. Yeah, I mean, in a cloud environment now, I feel like you say, hey, there's a vulnerability effects Ubuntu 2017, whatever. I can go and like look at my images and see what's running and do that audit pretty quickly. In Docker, it's like, oh, wait, do I have to go start looking at config files

to see what operating systems are run? Like that's not a good way of doing inventory. Yeah, and then you might not even know, right? Like if I told you, Joe, hey, go fix all the Docker files, you know, for all the Docker images that are susceptible to the Heartbleed vulnerability, you might be like, well, I don't, how do I even determine that, right?

Yep, and ops guys like hate that answer. But, you know, that's why it? Yep. And ops guys hate that answer, but that's why it's nice to have ops guys. I did get curious though, going back to one of the earlier things that I said about using team services here, and it's a little, I have

a partial answer that's not a good complete answer, but, which is I don't know. Because you can't it visual studio doesn't show you in the log what the token was you know what the credential was that was used that was passed into your script um it just it masks it with um asterisks or you know splat if you pronounce it correctly. So on the one hand, it kind of makes you think like,

oh, maybe it's not a one-time use then because who would care then? It's not sensitive, right? It's one time. But I don't know. So I'm not sure how that would work. Now I'm more curious. Now you want to play with it. Yeah. Well, now it would be the time to spin up the Docker container

and inspect that. Yeah, so that about wraps it up for this episode. And we've got a list of resources we'd like if you go to the website. I'm going to throw the book Phoenix Project out there. If you haven't read it, it's a nice kind of DevOps fun book. So I had to mention it. Pluralsight has a whole path on Docker. So multiple courses and

watch some of those. The Australian guy is amazing. He's very funny. See, MS Dev Show just did a great episode with Rita Zhang and it kind of goes at a higher level. It talks about Kubernetes and some other stuff that's really cool. And yeah, I got a couple other links here too.

Yeah, the last one there, the veggie monk, the one on GitHub. Dude, there are so many links and resources on that page. It is mind-boggling. Like I didn't even realize there was that much stuff you could find about Docker, but it is a huge resource. So if you're just curious about the things out there, click that one and scroll and scroll.

Jeez, look how small the thumb is. Yeah, dude, it's ridiculous. And so now it's, yes, my favorite part of the show. It's the tip of the week. Yeah. All right. So first and foremost, I want to thank everyone in our community.

So last time, I guess this feature was hidden and I just never bothered to notice this, but I had made a comment about like, hey, I really wish I could, you know, force Chrome to freeze the state, the mouse state

of a particular element so that you can expect it. And so we got a lot of feedback maybe starting, I think, in Discuss from Travis, but then I saw this comment everywhere. People responded back in email, Twitter, Reddit, Slack. So big thanks there.

I'll have a link to it that Travis gave us to Stack Overflow answer. But basically, in the Chrome DevTools, you can right-click on the element and go to for state, and then there's several states listed, hover being one of them. In my particular example though i still want chrome to if anyone from the chrome dev team is listening to create a keystroke because to just freeze the state because in our particular environment those dom elements were being added and removed from the uh from the dom so once you mouse away, it's gone.

You can't right-click on anything. So I still need something that would freeze it. Does that make sense, Alan? It does. Yeah. So big thank you to everybody that wrote in with that one. I really appreciate it. That was an awesome answer.

And I'm glad I know about it now. Next one is I've got a couple here for you. So of course I got to give you a get tip, right? So I found this neat article that was called the five get commands. I wish I knew about when I started coding and the one, it was the first one that he listed, but it was also the biggest takeaway for me was you know favorite one that i found that was in there uh that i hadn't already been using is i find myself all the time where like i will commit something and i'm like oh man i forgot a file and now i gotta like reset my my uh you know staged commit to undo the previous commit that I just made and then recommit it, right?

What? I only want one commit. What? No, you just hit up. No. Oh, let's do it again. No, no, no. I hate that too.

Well, the alternative is you just do what Joe is describing and you add a second commit in. See, my ultimate goal is when I submit that pull request, I only want one commit, right? So that everything's nice and neat and packaged up. And so that's why in my workflow, I was having to undo my commit and then redo it. And in Joe's scenario, he was adding an additional commit. But this one command that he added here was you could do a get commit dash dash amend dash dash no dash edit. So get commit amend no edit and whatever staged files you have at that time, it'll automatically just re-add those to the last commit, which is beautiful as long as you haven't pushed. That is amazing.

Never, ever, ever change history that has been shared. I cannot stress that enough. But if you haven't pushed that up yet, then you can do git commit, amend, no edit, and it'll add any staged files. They have to be staged now. So you have to add them first. You have to do a git add,

but yeah, it'll do that. And what the no edit is doing is it's just reusing whatever git message, a git commit message you already used. The amend is what's actually adding the files to the commit. The no edit is just saying like, yeah, the previous git commit message is good enough. Now you could leave off the no edit if you wanted to redo it. But yeah, I think I might have seen that command like a long time ago and just, you know, forgot about it or whatever. But when I read this article, I was like,

oh my, I do that so often. I'll forget something like, like here's the number one case is, I will, I love Visual visual studio okay i know what you're gonna say i love visual studio code so i will i will write i will i use it primarily for javascript though but for like the heavy lifting i've been playing around with rider but i also use visual studio for like any of the c-sharp stuff right And a lot of times I might forget to add a JavaScript file into the project

because unfortunately we don't have it globbed to star. Splat. Yeah, splat. But yeah, so I'll forget to add it to the project and then I'll be like, oh man, I got to go undo that commit just so I can save the project.

The CS proj file or whatever. Yeah, to re-add it to that. Or the same thing will happen with a database project where I'll add new schema objects, but I'll forget to save the stupid SQL project file. Oh my gosh. Every time. I forgot to save all.

Why does it do that? It added it to it and then it didn't save it. So yeah, that's an awesome command. And then lastly, in keeping with the theme of this episode in Docker, there is this one contributor here to the Docker community. And his name is Stefan Scherer. i think i'm pronouncing that correctly and he calls himself the docker captain he's a microsoft mvp and i'll share a link to his docker profile and his github profile he has pages and pages and pages of useful uh useful Docker images that you can use

where he's already taken stuff that if you wanted just small bits of the Windows ecosystem that you wanted to be able to build on top of, he's got small little pieces of it here and there that you can just piece together the parts that you want. You want chocolate he already built into he's got small little pieces of it here and there that you can just piece together the parts that you want right like you want chocolate he already built into a Windows instance he's already got it for you and he's got all of it available too

in his GitHub I just thought it was really great and there was a lot of great detail that he had out there too about it so I was just looking at the curl one like it's a really convenient way of running curl on Windows like it's really fast it's really easy it's using nano and once you've got nano on your computer it's going to be nothing to get that run and it's going to just feel like you're running curl

that's awesome i feel like there's a lot of really cool creative things you can do with docker is it my turn oh it's my turn that's okay so so mine is also keeping in the spirit of this particular episode and docker support in visual studio is what i want to point out so let's say that you just if you want to start a vanilla asp.net application or something you get that thing you tell it to build you the solution it gives you a nice thing with bootstrap and all that kind of stuff you can right click on the web project itself and you can go to add and then there's Docker support. Now, the thing that's really cool about this is when you add that, basically what it's going to do is it's going to add a Docker file and a couple of YAML files. And the really

neat part is then what it'll do is it'll set your startup project to that Docker compose file. And this is where things get neat. When you now run your application, if you have the output shown somewhere, like usually it's your debug or your console output window, if you switch it to the Docker one, which it should do automatically, you'll actually get to see all the commands that Visual Studio is issuing to launch your application. So you'll see where it's doing like a Docker compose and then dash F for the Docker compose file and then a dash F if you're in debug mode

to include the debug YAML file. And if you're in production mode or release mode, it will do a dash F and then the release one. So it's really cool because you can actually learn a lot just by watching what the Visual Studio team did in order to enable Docker in Visual Studio. So that's my tip. Have I talked to you guys about ligatures yet? I don't believe so. Oh, I don't think so.

This is one of those things that's better seen than kind of talked about. And this is actually, I keep talking about Matt, if I can count tonight. He introduced me to this too. There's a font I just found that he showed me, Fira code. And what's particularly cool about it, aside from just being like a nice, easy to read programmer font, which means like it's really easy to tell the difference between like l's and ones for example or zeros and o's is it's got these things called ligatures which means it uses a symbol to represent special combinations

of characters so if i do plus plus on the end of a number to increment, it actually, rather than doing two plus characters, it says, oh, I see what you're doing there. This is a special symbol. And it replaces them with a glyph of a plus plus. So if I do something like, say, triple equal signs, it says, oh, hey, this is a programmer thing too. So it smooshes them into a really long equal sign that's very obvious to you that this is a programmer symbol.

And it has the effect of making it really easy to distinguish between kind of typos and meaningful symbols. And so suddenly when you look at a source code, you don't just see letters, letters, letters. You start seeing the overlying structure of it really nicely. That's cool. Yeah, I don't know if you guys have seen this before, but it actually, in practice, it works out really neatly,

and it's super easy to set up. You basically have to enable ligatures, at least in VS Code, that's where I did it. I had to enable ligatures, which is just a simple true-false on, and then I set up the font, and it actually went out and downloaded and everything for me. It was just really easy. I feel like Joe is one step away from coding in emojis.

Yes. That's what this is. Keep the plus and equal poo. Apparently, the word ligature is used for other stuff. I guess it's really common for fonts to do stuff like, I'm looking at pictures of the F and I and the word fish. Apparently, sometimes the I dot will sometimes hit the top of the F because they,

it's because of how the letters are, because you got to get the kerning, right? Which is another one of those fancy letters. Fonts are hard, man. Anyway, they're like,

sometimes it's the F and I next to each other. Like, Oh, you know what? These are going to collide. Let's do a special graphic that represents both of these letters together. The actual combination of these letters. That's,

this is pretty nifty man yeah and practice it looks really cool I don't know if you're looking at fire code but if you just look at that it's like oh man this is really sharp it's open source that's awesome yeah the arrows are really cool that would

have been a good one or not equals do you know the exclamation point equal sign it makes an equal sign with a slash to it which is that is is helpful because yeah that's what you do in in uh math in the early days right yeah yeah this is cool stuff nice tip that was it for me so today we talked about a little bit of history lesson on devops and kind of how we got here we struggled to define devops but then came back around and finished strong on it well maybe yeah maybe maybe let's do it uh docker and then why dev should care and let us know if you have any questions is like we're still um i don't think any of us are real like

docker experts like i put in a lot of time on the weekends for it but I'm not doing this like I don't have the experience of someone who's doing this like 40 hours a week you know all week so I'm definitely struggling to learn so I'd love to hear your perspectives on it and let us know in the comments or in slack cool yep so with that subscribe to us on iTunes Stitcher more using your favorite podcast app. Be sure to leave us a review. You can head to www.codingblocks.net slash review. While you're up there, go ahead and check out our show notes, examples,

discussions, and more. And send your feedback, questions, and rants to the Slack channel, codingblocks.slack.com and check us out on Twitter, at CodingBlocks or, you know, we got everything. Go to CodingBlocks.com, You can find links to YouTube and everything else. Facebook. Spotify. Spotify. iHeartRadio.

iHeartRadio. It's all there. Right over there. Right over there. Right there. Right there.