1:02 Introduction and Housekeeping

1:02 Hello and welcome to the Rawkode Academy and today's episode of Rawkode Live. I'm your host, David Flanagan. Although, of course, you'll know me as Rawkode across the internets. Before we begin on today's session, taking a look at Docker Compose v two, I would encourage you to like, share, comment, subscribe this video, other videos, the channel, all of the bits in between. This helps other people find the content and makes YouTube's algorithm like me a little bit more. We also have a membership program available at the academy with an InfloxDB course and flight. Feel free to check out the membership options

1:33 on Rawkode.live. And if you wanna come and chat with over 500 other Docker Kubernetes cloud native developers and technologists, then come and join us on the Discord at Rawkode.chat. Alright. Housekeeping over. Let's jump over to introduce Brett Fisher, who needs no introduction, but I'm gonna give you a little one anyway. Brett Fisher is the author of Docker Mastery and has a really cool channel called Brett Brett Fisher, Docker, and DevOps, A channel that I'm sure we've all seen lots of times, love the content, and I'm very excited to have you on the show today. So hey, Brett.

1:49 Guest Introduction: Brett Fisher

2:06 How are you? Glad to be here, David. It's been too long. We haven't I don't know why we haven't done this earlier, but not lack not to the lack of your trying. I am bad at follow-up, so I'm excited to finally do this. Well, it's good that we get to spend a little bit of time together today and talk about Docker Compose and anything else that pops up as we go. So, yeah, I'm really excited. Give you a little introduction, but to anyone that's watching that is not familiar, do you wanna just follow-up with who you are and

2:15 Background and Questions

2:34 a little bit more information if you will? Yes. Sure. I I've been in IT for almost thirty years, so I'm getting pretty old. I got the the gray hair thing going on. And I like to say I've been I was doing DevOps before it was called DevOps because we didn't know what to call it. Right? It was just kind of optimizing and automating as many things as we could. Of course, that was the dark days of the the February when it was everything was hard to do. And about a year into Docker existing, I realized it was like the next wave

2:41 Guest Background and Philosophy

3:07 of tech. I just was convinced that it was going to be everywhere and everyone was gonna use it. And instead of being sort of an an implementer of change, I wanted to be a part of it. I wanted to, like, influence it, and and I love teaching. I love sharing with others. No matter what job or role I'm in in an organization, I'm always trying to share information and learn from others and collaborate. So I did that. And then eventually, I I created a course. I got to be a Docker captain. They gave me that title because I wouldn't shut

3:39 up about it, and I wouldn't stop bugging them. And then, you know, here we are today. I've got a team of people that help me manage over a quarter of a million people in a 80 some countries on my courses. Thousands of people every month in there doing that, and it's really it's fun. It's exciting. I also still do consulting. So I'm still a DevOps consultant because I like to do too many things all at once. And so I'm always learning I'm always trying to learn new stuff, especially in the real world. I think like a lot of us,

4:09 you know, I teach what I know and I teach what I've done. So it's hard for me to just approach a topic purely for educational purposes. I really wanna get my hands on and all that stuff. So, I'm always like, this year, if you've been on if you've my live show, I won't show up about things like GitHub Actions and GitOps and, automation essentially of all things in the DevOps space or even more into the ops space. But I I come at this a little bit different too because I I'm an ops guy that lives in a developer world. And a

4:40 lot of times, my perspective is slightly skewed from developer tooling because I'm coming at it from that operator mindset. But it's great because I get to hang out with a lot people that have different views than me, it's that's always a lot of fun. Awesome. Thank you for sharing all that. I'm gonna throw a random question that, you know, just since you early prediction of Docker being a game changing technology. Like let's remove Docker from the equation. Let's remove Kubernetes from the occasion. What's that next big one? Is there anything you could add on that you're you're playing with or you think

4:56 Future Tech Predictions (ARM, Multiplatform)

5:12 it's gonna be really cool in the next five years? Yeah. It's one I don't know. It could be a lot of things. Like, you could I I have a hard time figuring out what would be as big, and it's not so much Docker the tool. Right? Like to me, what I saw was that what I talk about is the three big innovations of containers. It was, and Docker kinda got them all right to begin with, the idea of the image format, right? So like those tarball layered read only sort of SHA hashed objects that you can send around and easily transfer from

5:44 machine to machine in a reproducible format. Like, that was fantastic because we'd had NPM and Gems and App and Git and all these other package managers and things, but they were always ecosystem focused. And so that that was great. And then they made a a really easy tool to run it, as we all know, the Docker command line, and then the registry to link them all together, right, which which is now becoming the generic object store. And we're storing Helm charts in there and all sorts of other manifests and objects and things, and becoming like that central

6:13 hub of artifacts that you get throughout your organization. So I almost feel like it was three it was a trifecta of great ideas that all landed at the perfect time. What the next one is, some people might say serverless. I feel like serverless is just a part of containers, and I don't think that the hardest thing for me with serverless is that it requires greenfields, so I I don't think that that's really a wave of, like, it's gonna hit us and then knock us knock us on the floor and give us a a big surprise like Docker did, you know?

6:44 Some some of it, I think, I feel like might be the the dawn of ARM computing everywhere, even though we've had ARM forever and there's a lot of people that are on that bad wagon, Right? Alex Ellis is one of the big cloud native advocates of of ARM. I feel like the fact that the fact that Apple has finally got in the game and doubled down by saying everything we do is gonna be ARM starting next year. Yep. It's forcing Microsoft's hand, right? It's focusing every other laptop or consumer grade PC tech company to adjust to that new

7:18 reality of thin and light, better battery life, longer lasting. But I think the real difference there is that it's going to make every developer a multiplatform developer. Like, eventually, we will all either be on a machine that's not the machine that our server platform is running, so we now have to develop on a different platform, or we're going to realize the benefits that we if you've seen the AWS Graviton processors and some of these things coming out where the indeed, we're getting 40 plus percent price to performance savings on servers simply by switching architecture. And so if that takes place first, then

7:56 us as developers and operators will be on a platform that the server is a different platform than what we're on because maybe we're still on an Intel machine. So the point there is that suddenly every developer that for the last thirty years hasn't really had to care unless you're in an edge case or you're making embedded hardware or you're you know, which obviously there's lots of people that do that. But for the rest of us that are just normal lives as Intel people, we've never had to care. And I I think that making developers educated about multiplatform is really, I think, gonna

8:28 provide a lot of long term benefits for the ecosystem and allow us to do cross platform things, give people choice and all that stuff. So it that it doesn't sound as exciting though, but it is to me. Because I I can nerd out on the hardware or the software all day long, so Awesome. There are really a couple of things there. Like, you mentioned well, how old is Docker now? Right? Seven, eight years? Eight. Eight We we passed did we pass seven or past eight? Shoot, I can't remember. 2013. Okay. So we've got a whole

8:43 Docker's Impact and Core Pillars

8:58 industry of developers with less than eight years experience. So maybe I've just always known Docker as a deployment mechanism. And you know, I I've been doing this for twenty years. You said you bailed West period like you said of the early two thousands where deployment was a that was weird. I am running a beta version of ECAM as we're about to find out today. However, yeah, there's that whole Wild West period where I know I won't put words in your mouth, but deployment for me in 02/2002, '2 thousand and '3 was tearing up a bunch

9:29 of files or doing a git pull on our production server and doing the build process on the production server under a directory that was called dot live, moving the old one to dot back and then there was dot back with a date timestamp. There's just so many people have never dealt with that. So I think Docker, you're right. It's just perfect timing and those three different tranches, there's three different problems that it solved. I think we're just perfect together. In fact, Docker always summarizes what builds ship and run. Like, those are the three things that they try to do really well.

9:57 Building on Giants & Returning to Local Dev

9:57 Right. Yeah. I mean, Kubernetes is obviously taking a lot of the oxygen out of the room and it's and it's always neat and exciting to play with new tech on it. But I feel like it's just, it's, you know, it's building on the shoulders of giants, right? And those three original features, I think, are still today. Like, I'm actually redoing some of the stuff in my Docker Mastery course, and I'm sort of doubling down on those three pillars of image registry runtime. And, like, if you understand those three pillars, then you can kind of regardless of

10:30 whether you're using Docker or Kubernetes or Podman or whatever, right, can sort of piece together the workflow of I gotta build it, I gotta get it places, and then I gotta run it. And I've kind of shaped a lot of my storytelling around those things, because they really haven't changed, right? We've standardized, which is great. We've got formats now that everybody's agreeing on, and all the tools can center around it. And so sometimes I think like, what's the next thing that will be so universal and it will be so loved that it will become a standard

11:00 that everyone will adopt in the industry? And I I don't know, man. Like, that's I really have a good answer for that one yet. Alright. No worries. But why don't we go back to something else that you said and then we'll get hands on with this Docker Compose malarkey stuff. Right? You mentioned that Yeah. You know, multi architectures, the machine that you develop against may not be the machine that you're deploying to. I think with the advent of Kubernetes and microservices distributed systems, that's what we're seeing is that people rarely are developing locally, at least maybe not on

11:29 a full application level anyway, which tend to ties in nicely to what we're talking about today with with Docker Compose. So we we posed this as a, should we still be using Docker Compose for local development? Is there a one word answer there that you want us to throw out? Or are we gonna do this through example? Well, I mean, if you've if you've watched any of my stuff or taken any of my courses, you'll know that I'm probably gonna say yes because I'm I'm a big believer in, like, streamlining workflow, minimalism. I am a fan of trying to create

11:36 The Core Question: Docker Compose for Local Dev?

12:03 server like infrastructure locally, but to a point. Like, Kelsey Kelsey Hightower is famous for, like, at least in my my mind, he's famous for saying, I don't run Docker locally. I just build Go apps, and then they get put into containers for servers. Right? I think he might have said that on my show one time. And I took that to heart because as your team gets more efficient and you move to more modern languages and tooling, you may be able you may have less need for containers locally. And then what I see is the opposite

12:39 happening some places where people are going all in on Kubernetes and making that their local development environment or a remote development environment because if you've ever tried to run it locally, you know that it will burn down your CPUs and your lap if if you sit your laptop on your lap Mhmm. With, like, yeah, with, like, steady steady three to 5% CPU usage. Even on on keys, k three s, there is just a natural loop that's happening in the background that's gonna eat up cycles. So and the reality is Kubernetes was never designed to run for a developer laptop. That

13:08 was not original scope of the project at all, but a lot of people are making it work there. And so I always look at say, well, to have to know Kubernetes to simply develop in a container is a lot, right? Yep. And I'm always working I spend a lot of time working with new people because of my courses, so I'm working with people that are still relatively new to containers, adopting containers and Kubernetes. And so I very much sympathize with the minimalist approach to just get me the containers I need, just spin them up with a one line command,

13:42 and don't make me start a bunch of other things and and have to know five different other tools before I can even start committing code. Right? So Compose can do that. Other tools, not so much. And Compose is kinda universal. I think Docker brags about 800,000 YAML files on GitHub for Docker Compose. So they they use that as sort of a bragging rights of, yeah, yeah, there's lots of Compose files out there. A lot of people are using it. Yeah. So, yeah, that's just Spoiler alert, we're gonna talk about Compose as a dev tool. We can

14:18 talk about comparing it to others, although I'm not an expert on all of them, because there's tons of there's tons of ideas out there for how to create a container based development environment. Oh, yeah. Definitely. Then maybe You might have dimmed someone on your show here. Yeah. I think I can maybe contrast some things as we go if if we feel it's pertinent. But we do have an interesting comment in the chat from the studio there. If you ask Brett Swarm or Kubernetes, he will say Swarm. Are you still back in Swarm? No. No. No. See well, CJ's teasing me.

14:37 Swarm vs. Kubernetes (Tangential Discussion)

14:45 Yeah. Hello, CJ. Yeah. I mean, I I was one of the last holdouts for Swarm. I'm not saying it's a bad tool, and I still use it actually, I still use it to run some APIs on the Internet for Slack integrations and stuff like that because I can you know, it it works with anything. I don't have to rewrite stuff into a serverless function or something, and I can just run some silly little web API on a DigitalOcean server. Of course, now we have all these, you know, automated Kubernetes systems that spin it up and tear it

15:16 down and all that stuff, so I I could technically do that. But I've had swarms there for four or five years, and they just keep on running. But, yeah, no. I mean, Swarm was just sort of the casualty of everyone wanted one tool instead of two, which I'm a big fan of having more than one option. I I I love that Nomad as a project is still a thing so that we get some different ideas in the ecosystem around running clusters of containers and that Kubernetes isn't the only thing in existence. But, yeah, I I don't recommend Swarm to

15:49 any business anymore. It's more for, like, hobby projects or, you know, Docker's still building it into the container run or to the runtime, and I I keep asking, and they keep saying they're still gonna ship it, but they don't have any developers currently working on it. So, Marantis, the company that Docker split into, basically, they Marantis bought most of Docker's employees as well as their closed sourced software. They did that a couple years ago, and there's they still have a couple of people working on it and building they're actually working on adding CSI support from Kubernetes for storage because one

16:24 of the the weak weak links in Swarm is and Docker in general is the plug in support for other volumes besides local volumes. And they're looking to just sort of adopt the CSI pattern so that people can write very similar wrappers or something around the the existing CSI drivers for Kubernetes, and then they'll just work in Docker and Swarm. But we're we're still waiting on that PR to drop. They're working on a bunch of them, actually. I was actually Team Swarm as well, and I got dragged away kicking and screaming just as the industry kind of insulated Kubernetes

16:55 against my will as well, however. Yeah. And as an ops guy, I want to think I'm I'm an ops guy who always wants things to be simpler, and the thing about Swarm that really spoke to me was like, man, if things could be this simple, how more productive would we all be? Like, how amazing could it be to have developers actually do more like, have more insight and be able to do things without feeling so handicapped around infrastructure and being, you know, cut out of the infrastructure game. Right? Because a lot of times there's a saying that

17:27 I learned years ago called the the ops mafia or the IT mafia, which is to say that IT, traditional IT and ops, tends to be a barrier for developers to get their stuff onto servers and into production. And until you get to a really well oiled DevOps machine, that still tends to be the case in a lot of organizations. And I'm a part of that problem. I'm a part of those people that put in security requirements and, you know, all these infrastructure requirements of you have to write all this YAML and do all these things and do all these scans and

17:58 all this stuff. And it was kind of like, man, if Docker could iterate enough on this idea, they might have a tool that could be presented and let people just get their job done, right? And and the rest of it all gets handled for them. And there's actually still an idea out there, not that we're gonna go down these rabbit holes. It's gonna happen. But there is this idea that Docker's sort of riffing on for if you build we'll get into this with Docker Compose v two, but you can build Compose v two today and have it deploy

18:14 Compose as a Bridge to Production (Kubernetes)

18:29 to a Kubernetes cluster using the Compose YAML. And so what if the idea eventually was the developer writes Compose YAML and then the ops layers on their manifests or their helm charts or whatever they need for the ops focused stuff, And there's just enough of an overlap that you don't you're not forcing developers to write, you know, Helm charts and customize, but they can stick with YAML simple in well, it's all YAML, but simple YAML in the Compose format with maybe a little bit of extras for things like Ingress. So there's an idea floating around about how

19:08 Compose could be that bridge because if you go back to the original Kubernetes goals of the project and the founders, a lot of them talk about how they never intended for the manifest YAML to be the interface for developers to deploy applications. They were always expecting something else, and that else has attempted a hundred times, at least a hundred times, in different projects like we see with Customize and Helm, and there's just a ton of other ways to do it, where you're describing your application and all the parts of it in a way that Kubernetes

19:42 can understand and deploy. A whole sync working on that and have been working on it for for years now. Yeah. It's a difficult spec for them to to anyone to write, really. Yeah. And you have to get like, you you have to take a lot of considerations into account, and then you and then you have to get buy in from the community, right? So you have to you have to get enough people on board that it looks like this could be a winner, right? That's kind like with Helm, right? Helm isn't always the right tool, but it it looks like the

20:09 winner. So we all gravitate to that first even though it maybe isn't the right tool for every job or the easiest tool for every job. And I'm kind of holding out for Compose. So I was so if I take my Swarm fan base, if I take my Swarm fandom and I apply it to just the Compose format and the Compose workflow, there might be a day where you can do a Docker Compose deploy, and it applies to a Kubernetes cluster, layers on some other things, and the developer and the operator can still exist and not step on each other's toes but

20:44 not have to know everything about everyone else's job, which is kind of one of the things that DevOps brought to the forefront, but also that one of the biggest stumbling blocks I find with teams, right, is that they now have to learn everyone else's stuff. Like, can I just focus on the things that I need to know instead of everything else? That's a real big challenge, I think, for companies, which is why us Kubernetes trainers are always training people on Kubernetes because they now all of a sudden, have to know it just to deploy their container app

21:11 when they previously didn't have to know it. Yeah. I I did Kubernetes workshop at conferences, at least before COVID anyway, and I'm always surprised that the workshop just keep getting busier and busier all the time. There's just always that influx of new people trying to learn the basics of Kubernetes and and even containers and Docker. Like, it's just and it's such a difficult space to education in, so people should definitely check out your courses. We got a question there that I think correlates quite nicely to what you were just talking about there with Compose files and applying them

21:13 Compose vs. Docker Stack & Kubernetes Learning Curve

21:41 to Kubernetes. But Yanis asks, Compose versus Docker Stack for local dev. Docker Stack attempted to do that deployment of a Compose to Kubernetes cluster, or am I mistaken? Yeah. Docker stack was like the production version of Compose. So that's a great question. Let's back up a second. So what we're talking about are two potentially different things. There's a composed file format, which both Docker Swarm, aka Docker Stacks, and Docker Compose, the command line tool, those both share that Compose spec. There's two different tools there, right? There's two different purposes. So Docker Compose, the command line, which

22:23 we're talking about today, that is optimized for local development workflow. And so whenever I teach developers, whenever I train consulting clients that I'm working with, it's always about let's get everyone all in on the Docker Compose command line as their developer tool because most of these people that are coming into containers are not, like, I don't advise learning Kubernetes as the first thing you're doing in containers, right? So I usually start them with Docker and we get the typical onboarding is getting their Docker files and whatnot. And then once they can get the parts of that

22:57 working in Docker, we say, okay, now let's do Docker Compose to describe your application and all the things about it in a very relatively simple YAML file. And then when they realize they can do a Docker Compose up and a Docker Compose down and that spins up entire environments based on the directory it's in, they kinda get that light bulb. You can see it switch on in their head, and they learn, okay, this is way easier than what I was doing before. And a lot of people even will avoid Compose or just not realize the power of

23:24 it, and they'll write shell scripts around Docker commands. Well, that's the entire point of Docker Compose is to avoid Its whole purpose is to allow you to avoid shell scripts and other developer tooling and just focus on writing a few YAML files that describe your app that really I look at as almost like a predecessor to describing it in manifest, which are much more verbose and complicated. So the long answer to that question great question, by the way, thank you is a stack is exclusively for Swarm, and Swarm is not a developer tool. So some of the things that you can do

24:01 with Docker Compose, like Docker Compose PS and, like, some of these other command lines that we'll get into, you can't really do that easily in Swarm, and it takes more work. And Swarm really concerns itself with, like, uptime and availability and health checks and rolling updates and stuff like that where Compose, Docker Compose, the command line tool has none of that, right, because it's really more about the developer experience. So we'll we'll talk about how, like, Docker Compose has things like depends on that allows you to start things up in order, whereas Swarm and Kubernetes aren't

24:10 Depends On and Health Checks in Compose

24:30 really about that. That's, like, production infrastructure. You have to deal with that in a different manner. But local development, usually, you don't want your web server bouncing for five minutes while your your SQL server's ingesting content. So so you want you you wanna optimize your local startup. You wanna make it really simple with pretty colors and local commands and status commands and stuff like that, and that's really what the Docker Compose command line tool is all about. It just so happens that the two of them share the same file format. So, I mean, we're gonna get to the hands

24:59 on actually writing and working with Compose in just a minute to anyone that's getting worried that we're now nearly thirty minutes in and we're still talking. But that's one of the reasons I still use Docker Compose format 2.3 or 2.4 because of the health check and being able to orchestrate the startup of the containers. But that was removed in subsequent versions. Is is that now working again, out of curiosity? Sorry. Was I was looking at the chat. Which which feature? Yeah. So in Docker Compose, always used version 2.4, I think it is, because it allowed you

25:33 to see it depends on service healthy, service start eat, and actually orchestrate. Because when you spend something up in development, it's very different to the production environment where you are happy for things to flap while things are again reconciled or whatever. But in development, like you said, I want to be able to start my MySQL, Postgres, import, and then have my web application container start up because it's going to do some sort of seed or database reconciliation. And I do need that ability, but I believe they removed the dependencies in later versions were just start this container first and that's it because

26:07 The New Compose Spec & CLI v2 (No Versions)

26:08 Yeah. Of something with version three. Yeah. And I'm gonna answer your that's a great question. I'm gonna answer yours and Roger Leanne's question on does Compose v three support limits like in prox? So the so, again, when we're talking about Docker Compose, the command line tool, not Swarm, we no longer have Compose file versions. So the spec, which what we can I can put I'm actually gonna put URLs in chat? So there is now a Compose spec, and it's on a single markdown document. I'm not sure if it'll let me post URLs. Oh, yep. Okay. It should be alright.

26:49 And so if you just go to, like, github.com/composespec/composespec, there's a spec in there. And what Docker did a couple years ago was they announced that basically they made the they made the specification, we can call it an API spec, but a specification for how you use Compose. Again, Compose is too many different things to many different people, but when it comes to this API spec, they formalize, which we never really had that before, that the Compose file version that we all typed version colon two and version colon three, whatever, that was an implementation of the

27:26 spec that they had never really formalized. So they formalized the spec, and then they said, okay, now it's gonna be up to the tool to implement whatever features of the spec that they want, but we're not gonna version the spec. So how this works is we're gonna talk today about Compose v two, and Compose v two is really a rewrite of the whole Compose command line tool into Golang away from Python. They're integrating it as a Docker plugin right into the Docker tool. Lots of advantages. But one of the big things about it is that both that and the now legacy

28:01 tool, is Docker Compose, now all follow in their latest versions the Compose spec, which means no more versions. So you don't have to worry about version two dot four. Other people don't have to worry about version three versus version two. Like, of that matters. The Compose spec is a superset of all of that and it includes all those features and then new ones. And so it's now up to the tool to look at the YAML and decide how it's gonna implement all the features and whether it's whether it supports the deploy feature or the depends on

28:32 feature or the health check feature. That's gonna now be up to the tool. You could say that Swarm is a tool implementation. Docker Compose command line tools is is a Compose spec implementation. And there's lots of other ones, like Compose with a k, which is a Kubernetes tool for turning your Compose with a CEML into Kubernetes manifest. That tool is also an implementation. AWS has an implementation for ECS. Like, there's a bunch of implementations now of this spec, and what's important for us is, in today's context, is that the new version two of the Docker command

29:09 line Compose tool implements that brand that, well, almost brand new spec, and you don't you and I don't have to ever worry about those versions anymore. Now, Swarm, just to follow-up for those people that are talking about Swarm, Swarm doesn't yet implement this new Compose spec. So it still requires you to put in like version three dot eight or whatever the, I think three dot eight or three dot nine is the newest version there. And if we went down the history road for a minute, version two was always kinda meant for local Docker Compose command line use,

29:40 and version three was always meant for Swarm, And they never really fully fleshed out adding all the version two features to version three. It wasn't like they didn't deprecate anything, which was a rumor on the internet. They just didn't really we weren't really ever sure how to implement depends on in a cluster. So they never really finished adopting that organization that's required in order to do depends on across many servers, right? They never really implemented that in Swarm, and so that was really the reason version three never adopted. And I and I'm like you, I love the depends

30:11 on feature. We can actually go through an example and talk about it because a lot of people don't know that it exists and it's pretty awesome. Alright. Awesome. Alright. We'll just quickly cover some of the comments and then we're gonna go over to the screen share and we're gonna start playing with some of this new goodness. So said said v three still has health checks. Yes. But it depends on functionality. It doesn't support conditional start thingies, which I'm hoping we're gonna play with today. APM asked us Docker Compose or for Podman. Not really, but as Kevin has commented, there

30:46 is a Podman Compose. Feel free to check out that project. I think it's on the containers, git hub Com / containersorganization. Yeah. That's a good I'm I'm glad for that because I had forgot what the answer was. I knew that there was a way to do it, but I I could remember what it was at Podman. And so I guess that would be we have to look at it, but I guess we could say that, hopefully, Podman Compose is implementing the Compose spec. So that way, we will start getting because if were to dive and nerd out in the Compose spec, there's

31:19 actually a lot of interesting ideas and things that could be implemented in various tools in various ways to allow us to all use this simple YAML file format to do actually more of the things that we don't think Compose is for, right, like Ingress, Well, more more advanced things than Ingress, but I was gonna say storage, but storage is kinda already in there with the drivers concept. But that's what that's what we really haven't seen a tool take to the next level yet is taking the Compose spec and turning it into a production ready man almost like manifest light. Right?

31:58 And there is that ECS integration, like CJ is mentioning, and they have some new stuff in there as well for Azure ACI as well as AWS's ECS. So you can you can either check out my channel or Docker's channel. People have shown about how you can use Docker command line with this new new Compose tool to not just deploy to Docker, but also to deploy to clouds like an ECS cluster or an ACI server inside of Azure. So Docker a a side comment on this is that a lot of people, when they think of Docker in the old ways and how to

32:32 deploy it, we think of things like Docker machine, other tools for setting up Docker on a server. And since Docker is now focused as a company, they're focused on developer tooling, they're not trying to create servers anymore. In fact, they're almost intentionally going away from being the we do run times on your servers, so build a bunch of servers and do our stuff, right? Their approach is now, hey, look, the clouds have all got their APIs for how they wanna do container deployments, and they all have different interesting ideas on how to do that in various ways. So

33:03 now what we're seeing with this new Docker Compose CLI tool is it's using the Compose spec to allow you to deploy directly to those ideas rather than, like, you know, we mentioned Kubernetes directly to the Kubernetes API and then to something like ECS, which is a different cloud API, and then something like Azure ACI, which is a different API. So now Docker is you think about it, they're they're they're adding integrations to integrate with cloud APIs, not with their daemon, which is totally one eighty from, you know, the first five years of Docker's life, six years of

33:39 Docker's life. It was all about the Docker daemon is somewhere, you have the Docker command line or the Compose command line, and you're talking to that daemon on a TCP port. And now, what they're really looking at this is, well, we have that, and that's great, but we're going our future is really in integrations to clouds, and we're gonna use Compose as the way to do that. Alright. Awesome. I think we should get you I think we get your screen shared and we start having some fun with this new Yeah. CLI v two. Too much talking, not enough doing.

34:06 Getting Started with Compose CLI v2

34:18 No. It's a good good conversation. I think it adds a lot of context and people can understand the history of these tools and and and where it's going. I always think I'm always amazed, you know, the original Docker Compose written in Python, I think, was maintained by one person for, like, the last two or three years of its existence. Yeah. One or two main people in there and, yeah. Well, seeing it running Go with the spec just brings a whole new lease of life to it, which is really exciting. Yeah. There was I mean, there was a conference in Berlin, a Docker

34:49 conference called the Distributed they only did it one time. It was 2016, I think, maybe yeah, 2016, in Berlin called the Distributed Computing Conference, and it was right I don't think it was KubeCon. It might have just been, like, a Linux Foundation conference, anyway, in Berlin. And so everybody was there, and it was a really interesting conference because a lot of the ideas that we're still seeing implemented today in distributed computing and in Docker were first there, like distributed storage, a lot of it distributed storage that's connected to containers automatically. Those are still things that are being fleshed

35:27 out. But one of them was we're gonna rewrite Compose in Go, and then we're gonna be able to share libraries from Docker and Compose to use the same underpinnings instead of two different languages and two different libraries. It's sad that it took this many years to get there five years later, but at least it's here. And it's it's an opportunity because I think there's a lot of edge cases around the Python. Like, most people don't realize Docker Compose uses Pyinstaller, so it actually it adds two or three hundred milliseconds to every command in terms of delay unless you're installing it

36:01 with PIP because it has to unpack the binary, run Python with the with the scripts, and then do this stuff. And then, of course, debugging when you get errors in Python is always interesting. So, yeah, there's lots of good news here. In fact, let me share my browser first because let's just let's go over real quick for those that aren't savvy of how even how to get this before I start demoing it. I I don't think I can share I don't think I can switch Windows. I think I just have to stop and start. But if the good news is is if

36:32 you are on Docker desktop, you already have this. So this new version is Docker Compose instead of Docker Compose. So it's a plugin sub command of Docker, and if you have Docker Desktop, it comes with it. You already have it. So just start typing Docker Compose from now on, and all your original commands work, and then there's a bunch of new ones. But they have their own repo, so instead of it the old repo was github.com/docker/compose. The new one is I'm gonna zoom in a little bit so it's easier to read. The new one is

37:07 Compose CLI, so Compose dash CLI. And if you scroll down, you can find, for Linux people, there are people that aren't using maybe they're using a VM and they're not using Docker desktop. You can get install instructions there, which is essentially the newer instructions are essentially have Docker installed and download this plugin. And there's a format for Docker plugins, and they go in a subdirectory of your user directory and all that stuff. So they they get you set up and running, and then you should be able to go to your command line and do that. By

37:38 the way, I think I did I link the spec? I think I already linked the spec earlier. But that this is the spec, which is this very, very long single markdown file. I'll put the Compose CLI there in the people. But let's switch over and man, this this this shares this is for later feedback on Ecamm Live. This the sharing screen button is right next to the hang up button. It's super super Well, I thank you for not hanging up on me. So Right. That would be awkward. Okay. And that concludes today's episode. So you'll notice that when I do a Docker

38:23 Demo: Basic Compose CLI v2 Commands

38:24 Compose version so this is my old Python runtime. So you'll see, like, Docker Py, which is technically the library that Compose is wrapped around and then c Python. And so now if I do a Docker Compose version, it this is the Go binary that's running from a subdirectory of the plugins where all the Docker plugins are at. And if you do a Docker info, you can see in that info list, you can see plugins that are installed in your Docker. Some some of us may not realize we've actually had plugins for a while. If you're running Docker Desktop,

39:06 Docker Desktop will automatically add a scan. So Docker space scan is which is from Snyk. So it's like a Sneak plugin, and then Buildx is the new advanced builder for fancier and faster building of your Docker images. So those are all plugins already. So now we get this new one Compose, which they're they've been iterating through the release clients lately and still squashing some bugs and stuff like that. I tend to use it every day. I've been do trying to do it all year. Obviously, as it's matured, the bugs have been less and less, and I

39:35 think I'm only tracking, like, one bug that only happens every so often. So then we we when we do those Docker Compose commands, if you're someone who's used Compose before, if you just type Docker space Compose, you see all all the typical commands. Right? And most people actually when they use Compose, they use, like, two we all know, like, the Docker Compose up and the Docker Compose down. Those are probably the first two that everyone learns, and they might learn Docker Compose build, which builds all the images that are inside of that one Compose file, which is convenient.

39:45 Compose Subcommands

40:12 But when you think of Compose, think of it as I should never have to type an actual Docker command without the Compose because the Compose is designed for a project mindset. So all of these commands have the scope of whatever current Compose YAML file you're using. So if I use if I do a Docker Compose PS, I will only see listed the containers that are in my current project, not maybe other containers that I got running somewhere else on machine, my local machine, my server, whatever. So that's one of the reasons I say it's the developer friendly tool because a lot

40:46 of us may need to run multiple projects at the same time if we're trying to integrate two things together, or maybe we don't wanna spin something down while we go test something else. And so these Compose commands are designed to wrap the Docker and sort of filter out anything else in Docker that you're not dealing with at the moment in your current directory. And so a lot of people will be surprised to find things like Docker Compose top, Docker Compose. Now we have we've had PS, but now we have this new one, LS, which actually gets us

41:20 if you have many projects or many directories where you've done Docker Compose up, you can now see a list of all those. And so you because sometimes we we forget, like we close some windows, we forget, oh, man, I got Docker Compose running somewhere. I don't remember which directory it's from, and it's not super obvious how to get back to them. But now in any directory, you can just type Docker Compose ls, and it will just show you if you have any Compose projects running anywhere on your system. And I don't. Yeah. What typically would

41:49 happen to me is I'd run a Docker Compose app and it would complain about the port bindings, and I'd go, oh, I've left something running somewhere. Exactly. And that's exactly when you would use a Docker Compose OS. I do that all the time as well. If you have a Docker desktop GUI, the GUI now actually has a lot of this built in too. I'm not gonna show it, but the dashboard GUI now has a Compose, it's Compose aware, so it will show you a Compose project and allow you to see the logs. You can start and stop it all

42:18 from inside the GUI in case you're more of a GUI person. But, yeah. So that's a really nice they added that right up front when they started working on the v two, and that was a nice add in because it was one of those things where you hit it and you're like, well, how do I deal with this problem? I do a Docker PS, and I see a whole bunch of containers, but I don't know where they are or how to stop. I don't wanna have to manually stop each one of them, especially if you're, like, a microservice

42:43 person. That would be a lot of pain. So we have all the other typicals. Like, you can actually copy files in and out of your Docker Compose services because remember, all these things are services in Compose. You can copy things in and out. You can exec into these, and you don't have to know the container name. So what I see, one of the big mistakes I see people using is they'll create a Compose file, and I've done this before I learned how this worked, but they'll manually assign container names. So there's a YAML value that they'll put in their file that says

43:16 container name, and they'll hard code the container names, and that tells me that they're still using the Docker command line. They're not using Compose for everything, because if you're using Compose for everything, like exec, ps, logs, kill, start, stop, restart, like all these commands that are managing it, you're using the Compose commands for the service name, not the container name. Because again, you can have a service with multiple containers, which is why when you start up something in Docker Compose, you will see like Docker Compose, you know, service name dash one, you know, and then dash two and dash three if

43:50 you do multiple replicas. And so it it can do that, but if you assign it a hard coded container value, you can never spin up more than one replica. It's kinda like having a Kubernetes pod that's manually named and then you try to spin up an exact named pod. You it won't work in that same namespace. So that same thing is happening here. One of my biggest pet peeves, I think every Docker tutorial and Compose store on on the Internet has container name hard coded and there's never a single good reasoning. And I always say this to people at conferences as well.

44:22 There's not one single good reason for naming a container. Using container underscore name, just remove it immediately and it's it's never good. It I I don't even have to ask why they do it because I I have a feeling that they're doing it because they they don't realize typing and talking talking at the same time, by the way. They they don't realize that whatever the command they needed to use for that container name probably existed in the Docker Compose command line and it's probably easier. Yeah. They're almost writing a shell script to do something with that container and, yeah, there's

44:58 no need to, like, can work around it. Right. Oh, I just realized I wanna be using Vim today to make it easier for screen sharing and my Vim is in bright mode. So, we're in I do like the mode though with the the flames on it. I'm not sure how you've got that, but that is it. Oh, this is this is not my skill set. This is SpaceVim. So look up SpaceVim, which is kinda like a Vim installer packager manager. It's it's a and it does all this stuff for you. So, like, if I just do this, it will

45:37 actually update a 34 plugins that it manages, including, yeah, including my font, all of the the stuff at the bottom. Very cool. I like that. Probably shouldn't have done that. I guess it's a variation of the Space Max, which is the Emacs within bindings, and now there's a SpaceVim, so Yes. It's mostly it's it's got a large community. It's mostly managed by one person, but it's regularly updated. I've been using it for years. I used to use SPF 13, I think, and it that kind of died a little bit on the vine. Wasn't wasn't getting maintained.

46:13 I think so. I've using SPF I was brave doing a live update. Yeah. Update your plugins live. What could go wrong, Brett? Come on. Yeah. I do it all the time. No big deal. It NeoVim or just Vem8? Do you know? Is it what? Is it using NeoVim or is it using Vem8? It uses both. And so sorry. For me, my my a Vim command is just aliased to in Vim. So you can use either one, and it will plug into both. It installs into both by default. It it use it uses your Vim RC

46:44 and all that stuff. I also enable italics for local use because I love italicized comments and stuff. Well, there goes my productivity for the rest of the week as I explore switching IDE again. So thanks. I had yeah. Right? Like, I I you're not the first person to tell me that, and I'm going to give you all a URL for later so that we don't spend the episode on this because it's a it is a rabbit hole and I love talking about it. Yeah. Let's just forget Compose. Let's just play with your Vim sale for

47:11 the next thirty minutes. So I'm gonna put in the chat brettfisher.com/shell. So all of the things that I use in my shell there, including italicized, true font true true color fonts, all that stuff is in there. I'm actually going to not use the shell because I realized I love using Versus Code, and I'm just going to do that for today. So where we make we made temp Rawkode. So I'm just gonna share that. That way, I don't have to switch back and forth between Windows. This this thing doesn't I could share my whole screen, but I'm on a four k.

47:50 So it not that I couldn't share the whole screen, but it would be very small for everyone. So let's just do my new favorite editor, Versus Code. Alright. So we're just gonna create a Compose file, and then we're gonna run some things. Do we have any questions in the audience that we haven't addressed yet? No. Just a confirmation that SpaceFim is Spacemax inspired and some love for the rendered corner power lane prompt, which I think, yeah, was looking pretty good. We could I could also demo off what's what's gonna happen during this demo is I'm I'm demo demoing Copilot, GitHub Copilot because

48:00 Creating a Compose File

48:31 it I am hooked on Copilot. I like, now I don't turn off anymore. It's just so it bleeds my mind. Yeah. It's unbelievable. It's a little weird. It's a sometimes I had a friend on the show, and we we kinda tried to beat it up for DevOps purposes, and it so we just spent an hour. I recorded, like, a week's worth of using it and recorded a bunch of little weird oddities, like, using it for markdown editing. It's soup. It just starts writing words for you based on your previous words, and you can fill out a whole markdown

49:05 file in gibberish. That doesn't really make any sense. It'll actually auto create links for you that don't work to things that don't exist. I I don't yeah. It's it's a little wild wild west right now, but Can you drag your Versus code window a bit wider? You're breaking my layout brick. Come on. Oh, man. It's always hard to figure out that the right layout. There we go. There we go. A little bit a little bit more? A little bit more? Yeah. You can go more. Yeah. There we go. Oh, you're Yeah. See how yeah. It's already it's already telling

49:35 me the wrong thing. It doesn't know Compose files. Alright. So we got a comment from Paul saying that Brett is posting links, but they aren't appearing. Yeah. I'll just go check that now. They might be held for review because there are links and I can fix that. Yeah. Let me go check that. If you make me, like, a commenter or whatever Yeah. I think it auto works. If you have all the chat stuff, the security stuff enabled like I do. I'm not gonna do that. I'm gonna do NGINX. So we're all familiar to this with this

50:12 standard format and, like stuff like that. And then my terminal. So there is a Docker tool that you can get for Versus Code. I don't even have it showing up here, but you can get a Docker plugin, which I highly recommend. And it will it can do you can see things in here and do things like and you can actually run Compose commands from the command palette. But I'm just gonna use command line because I think a lot of people that's what they're used to experiencing, and they do that. So if I'm in this directory, then

50:56 do a Docker Compose PS. But right away, you'll notice that it this new one uses the new builder, which the new builder can do things much more concurrently, and it's actually really smart. There's a ton of advantages to it, but one of the things it'll do is if you're using multistage images, it won't build stages that you don't need for your current target in case you're someone who's in the multistage building. So that's a nice thing is the new Docker Compose will just use the new build kit by default. And so I did that. Docker

51:34 Compose PS now. And you'll see that I'm gonna hide the files. We'll see that we've got two services running. Right? So this is kind of just sort of proof that by the way, it's it's proof that it works like the old one works. And I can also just type in Docker Compose with a dash and get the same you can kinda compare the old and new formats. So one of the things they've done with the new command is they've sort of refreshed the format. It now it it they they're fixing some of the old quirks

52:04 since they kinda had to rewrite everything. So we'll see that. And then I can do things like Docker. Most people don't realize you can do Docker Compose top, the next, and that will show me the processes running inside of that particular service. So I can do that without even having to go inside it. I can pause things, stop things. So, like, the workflow that most people, if they're not familiar with it, you do Docker Compose up to start everything up. You do the Docker Compose down at the end of your day to stop it all except for

52:36 deleting volumes. And then you can do things like Docker Compose pause while you go to lunch, and it'll let your CPUs calm down because it'll just sort of freeze the CPU but won't stop the containers. You can also do stop, start, restart. So those are all the common commands. But I think the value of a particular demo that we wanna talk about, because we talked about that depends on and how that works, is to talk about two things, really, two major things that most people don't know about that would probably help their workflow in Compose, and

52:53 Demo: Depends On with Health Checks

53:11 that's one talking about your depends on example, and the other one is talking about profiles. And profiles, for those of us that are getting real world Compose files that are getting very large, maybe we have dozens of services in there or just a dozen or even just five, you may not wanna spin those all up at all at the same time. So profiles is a new feature in the Compose spec that the new Docker Compose tool now implements that allows you to add a service line, and you can basically tag your services and then bring them up and down in groups

53:43 based on this tag, which allows you to do things like maybe you have a startup script that seeds your database and does a bunch of things, and you only wanna run that once. Well, you can now do that by specifying a separate service, and you can run it as a one off, but it'll use all the Compose stuff. So it won't always run it unless you specifically run that profile. Other things you can do is maybe if you're a developer on a larger team, maybe you're the front end developer, but the file the Compose file's written for everyone. So

54:14 it has the API back end, it has the database, it has the worker jobs, but you're really just the front end person and maybe you're using React. And you really only need the you know, you don't need the worker or all this other stuff in the background. You really just need the API and the database. So you can now use profiles so that you can now You don't have to sit there and manipulate each individual service, like just doing the Docker Compose up of a specific service. You can now specify a group of services by tagging

54:39 them. That's awesome. I've lost track of how many make files I've had to write. This spins up just the right amount of services for what I was doing or even to spin up a service which normally has replica zero, but you're just trying to run a single command, like the database migrations and stuff. Yeah. Yeah. That's nice. I like the details. And that's the thing, right? And Docker's still trying to iterate on this stuff, so they've got some ideas around how to even make take this further for one off tasks. I think, really, one of the things that interrupts developer workflow

55:09 is that we're all getting to the point where we're all starting to have common tooling, right? So we're all starting to learn Docker. We all know some basics of Docker Compose. Maybe some of us are saying that basic kubectl commands are there, but then every team seems to have these shell scripts and make files and other utilities that are part of their workflow for local use, and I'm gonna say I'm just gonna say watch this space because I think Docker is trying to figure this out a little bit better using this new Compose syntax, maybe adding some

55:41 more features in the future. But I have another repo that I'm gonna I'm gonna steal some examples so that we don't have to manually watch me type all this, which, you know, I'm sure that's super exciting for everyone. So I'm going to throw in something like this. Let's pretend that these servers, which they don't really, but let's pretend that these servers depend on a database because, obviously, these are just standard NGINX servers. Yep. But the Postgres server, if I throw it in and I just launch it, it actually now that think about it, this won't actually work because it needs a password

55:50 Healthchecks

56:26 nowadays, so my example's already out of date. But one of the things that you wanna do in these files now, and what we're gonna I'm gonna not bury the lead, and we're just gonna add the depends on. Can also change that variable for the the password if you wish as well. I think it's just postgres underscore password or postgres underscore password to get it to start healthily. Look at that. With that. Yeah. That's that's GitHub Copilot in action right there. Alright. So let's assume that actually works. So up here, so there's two parts to this puzzle, and what we're trying to solve

57:07 is what you mentioned earlier, is I want I don't want my front end app to constantly bounce every time I do a Docker Compose up because it's waiting on the database to start. Well, in Compose v two, like you were saying sorry. Not Compose v two. That's that not Compose command line v two, but in the Compose file version. Back in the day, we would type version two dot four. Right? And that would only work with the local Docker command line tool, would not work with Swarm, which is fine, but it would allow us to use this

57:38 depends on, but most people didn't know about this. They didn't realize that they could extend the depends on to not just say depends on DB, because most people would do this. They would not have this line, right? It would not have that line. They would just have the depends on DB, and then they would realize that it doesn't really wait for the database to be ready. It just starts the database first so that the DNS is available. Yep. And so then the app would still crash because it's still waiting on the database to start or whatever.

58:12 But in like two dot two or something, they added this feature years ago that there's two different conditions here. You can say condition start or condition service healthy. And what we want is service healthy, which will use the Docker health check, and then we add the health check. So that's what I've done down here. And if you go looking for Docker, if you just Google GitHub Docker library health check, those four words. Someone will probably find it and put it in chat. Docker has a library of sample health checks for almost all the common open

58:46 source database technologies. So Redis, Postgres, MySQL, I'm not sure if Elasticsearch is in there, but they have other stuff, MemQ, something like that. And they will they will give you this example of how to add a health check to a container really easy so that you don't have to make a custom image or anything like that because you don't wanna have to do that. And then what happens is now when this starts up, and by the way, that's it's the here. So if I do that and I go back, Docker Compose up. Oh, right, I took the version out.

59:35 So we don't want that version anymore because now we're on Compose spec. So basically, if you've been around five years, you know that the version one of the spec that we all were using way back in the very early days of Compose, before we was even called Compose, that was there was no version for that. But now the tooling, if there is no version listed here, assumes you're using the latest version of Compose spec, not the old, old, old v one from, like, 2015. So that that like, most people probably wouldn't even think about that, but

1:00:04 it's smart enough to know the difference. So if I do a Docker Compose up here, it now recognizes that it needs to load a database because I have set the depends on. Well, I've just set up for everything, so it's gonna start it all. But it's going to hopefully start that postgres correctly, and then it's going to wait until the database Ta da. Yeah. So you notice that little pause there because I do this on NGINX one. Didn't give NGINX one what it depends on, but I did for NGINX two. And some of these examples, by the way, I'm

1:00:44 just gonna put another link, are from a DockerCon twenty nineteen talk I did. I'll put this in chat for everyone. So some of those examples are in there where I show off how to use depends on. Ignore the part of that video if you watch it about it needing version two because obviously in 2019, we still needed the version two file format, but now we don't. So yeah. So ta da, that's the demo of that one. Now I would do that on everything in a Compose file. If I'm on a real team making a real app,

1:01:13 I would have depends on everywhere because what I would do is my so my front end developer, I would tell them, hey. When you do Docker Compose up, you're probably gonna wanna use Docker Compose up of just your front end app. And so now it's gonna be smart enough to find all the other services that it's depending on, and it will start them first, wait for them to start, and then you can actually have multi chain sort of startup order where you the database then starts, then the API starts, then the front end starts. And so you and with me, I actually

1:01:49 have another demo that uses I use most apps nowadays all require SSL. And when you're dealing with cores and other front end issues, you usually wanna develop with SSL as well. So I have another repo, if you just go to my GitHub, that's called Compose TLS Dev Proxy or something like that. And it basically auto creates a self signed certificate or even less encrypt signed certificate, uses traffic, and puts it all in your Docker Compose file so that you can have a boilerplate TLS wrapper around every one of your web apps without having to customize it for every web app.

1:02:24 And one of the things you do with that in Compose is that you set it all in the depends on so that essentially what you're saying is all my front end apps depend on the proxy to start first as well as the database. And so now you get this wonderful startup order and your front end team, your back end team, they can all just specify the one thing they wanna work on when they do the Docker Compose up command. In this case, I'm just wanting to start NGINX. And the Compose is now intelligent and aware

1:02:51 of how things are healthy or not, and you get this wonderful startup order. And then your team will love you, right? If you write this for your team and give this to them if you now do a Docker Compose PS, you'll also notice that oh, they've all exited because I did a up Now they're gonna stay running in the background. Detached. And as soon as that's done, if I do the PS again, you'll actually see healthy there. So we get this little extra information of maybe why things never started because if your back end app

1:03:00 Monitoring Service Health and Staying Updated

1:03:29 doesn't start correctly, you're still sitting there waiting and waiting on the front end container to start. You're like, why doesn't this thing start? Well, eventually, there'll be a time out, and it'll just not try anymore. But you'll you can see this as a indicator for maybe why your your depends on doesn't work. Nice. Any questions in the audience? Yeah. If anyone has any questions, just drop them into the comments, and I'll read them on to Brett as we kind of progress through this. Yeah. But it's it's it's nice just to see those conditions working. I use them heavily,

1:03:59 and we'd go to conferences and tell people never to use v three. It's only for swarm, and I hate it. It's awful. I don't like it. Use this one. And people kept moaning at me saying, don't tell us to use old versions or downgrade. And I'm like, it's not a downgrade. It's a different use case. Yeah. And I had this big massive rant with so many people, and now it just works. And I I actually I've not followed the Compose spec. I haven't used the new Docker subcommand plug in Compose, so I'm really, really happy to see that

1:04:25 working. Yeah. I I also love it when I have people on my show that teach me something. It's like I'm getting free training. So I I sympathize with you. I know your joy, especially with the tool that you're already using and you're learning new stuff about it. Because one of the things I think that we're innately bad as humans at is we tend to, especially those of us that are just ravenous learners, right? We will learn something, and we get to a point when we're learning that we tend to taper off our learning unless we have a new problem that we

1:04:56 can't solve with it, right, or a new thing. So a lot of things that I'm experiencing now with people when I do trainings is they have Docker and Compose knowledge, but they've not really kept up continually over the last three or four years, and they need a refresher, right? And that would almost be like a good course for someone to do is, you know, Docker Docker refresher or Kubernetes refresher. That's just the 2020 features, know, assuming that you knew it all from 2018 and 2019, just the latest features of 2020 and 2021. Because I think we're innate, most of us

1:05:28 are innate, at least I am, really bad at going back to a tool, learning new things, figuring out what things in my files are now out of date and wrong. Also, shout out to linters because that's those those are the things that will help you know that your old stuff is old. Linters will often be updated to the newest spec. Anyway, so if we don't have any specific questions on this one oh, so use Compose v two plus the Compose CLI plugin. So the Compose CLI plugin is Compose v two. Okay. So when we when

1:05:51 Clarifying Compose v2 Naming

1:06:05 we're referring to Compose v two, that that exact word together, that is Docker's way of saying we're rebooting Compose into the Docker command line. And I know it's confusing confusing because there is a Docker file version two and version file version three. We're not talking about that when we say now Compose v two. Docker has chose to brand, for whatever reason, naming is hard, naming is like the hardest thing, they've branded this new reboot of Compose into the Golang and inside to the Docker plug in. They're basically saying this is now Compose v two because they're rewriting it from scratch. I would

1:06:47 have preferred them to avoid all confusion and just call it Compose v four or something. And one of the reasons they said this, and it does make sense, because if you look at the Docker old command line, if you understand the difference between the file format and the command line, the old Docker Compose version was perpetual version one. It it's not the latest version is one dot two nine. So when they release this new version, it will, you know because it's still kind of in release client. It is now gonna be the command line client version two.

1:07:20 What I'm saying in all your files, all your YAML files now need to just remove their version format forever. The version YAML file thing up at the top can just be blank forever. No version needed. And what that means is is that all the all the clients, except Swarm because it's still not been updated. We don't know when that's gonna get updated, if ever. All clients, all things that consume the Compose file, those are the things that are now responsible for adopting whatever feature you want, like, depends on, okay? Sorry for the confusion. I know it's a

1:07:58 little much on on those two things. Alright. Let's jump to our next demo, and we can come back to the questions real quick. Sure. So the next next thing I wanna talk about is let's do let's find something else here. What if we started Oh, sorry. It's like Ghost. Maybe I have oh, Ghostblog. I love Ghostblog. I use Ghostblog forever ever since they first launched way long ago. It's a nonprofit. I'm a big fan of it. So not that WordPress is bad, but I love Ghost. It's also written in Node. Js. So I use Ghost so that you can just

1:08:02 Introducing Compose Profiles

1:08:48 start up a Ghost server. I think this is actually all I need. I'm super positive. But let's say that you have, let's say that your company has a single Compose file and you really have them for the front end developers that are managing the website, right? Maybe they have the website and then they have the blog. So there's a couple people that focus on the blog infrastructure, but they also need because maybe it's proxied on a subdirectory of the main website or whatever, you maybe need to have them all in the same Compose file. But you don't always need them all

1:09:20 at the same time because maybe there's the React front end people making the fancy website and then there's the ghost people just making the blog or whatever. So I'm creating a fictitious scenario for why we need this. So if we go I'm sure that there is a web browser plugin for Versus Code because there's a plugin for everything. There is a web browser extension. Do you use one? Do you recommend one? I don't use one, but I I read like one of those listicles just yesterday about these top 10 Versus Code extensions. And one of them was just bring your web browser

1:09:52 and instead of switching to Chrome for for debugging. Because I think Versus Code, the the debugging support in the IDE now supports the extension that gives you the browser so you don't have to speak to, like, a real Chrome or anything. It seems cool. Let's see if I still got up my history. Yeah. Anyway, I'm I'm distracted on this, but Oh, wow. Oh, that's deprecated. Dev tools Chrome. Yeah. Someone in chat knows knows a good one that they There's one called browser tab. You know, it's not got many installs, so You go wrong. Browser tab. Oh, browser preview. That's the popular

1:10:39 one. Yeah. I found the listicle. Real browser preview. Yeah. That's a browser preview, though. Anyway, I'm not sure if that's gonna work, but because I want a preview of the YAML file. I just wanted a browser tab, so we don't to switch. Anyway, it's a browser tab. You you got a URL bar and everything. Oh, okay. Okay. I'll try that. What's the worst thing that could happen? I know. It's someone's gonna have access. It's like, please log in with your GitHub account. Oh, now you have everything. Browser preview. Alright. Alright. Yeah. We got another vote for browser preview

1:11:20 in the comments as well. So Oh, nice. I'm trying to think how I how do I want my window I don't want it to be on the tide there. So you probably only need the last command. Alright. So what are we doing? We're doing oh, I'm gonna go look at the Compose spec real quick so that I can show we can sort of correlate these things together. If I go to the spec, then oh, can I do find in here? Will it will it do find inside the document? Probably not. Let me let me find the actual header.

1:12:14 There we go. That's what I want. Profiles is a new feature in the spec, and so the spec is really just talking about how it should work. They give an example of maybe what it would like look like in YAML. And so we have the service at the top. Sorry, the services, the main services, then the service, a single service, and then the profiles that it's going to be a part of. So by default, they're all technically sort of a part of the default profile, but you can add custom ones, and so that's what we're gonna do

1:12:19 Demo: Using Profiles for Service Groups

1:12:48 for Ghost. And maybe we're going to say, for profiles, it only needs to be a part of the blog profile. And then everything else is a part of just the default. So if I do a Docker Compose up oops. No. I didn't want to do that. If I do a Docker Compose up, Notice that it still doesn't show well, let's just make sure I save the file. No no tricks here. Okay. You'll notice that it didn't doesn't show that ghost blog part. It's not it's not considering it a part of the project because I didn't specify that profile.

1:13:36 So if you look at the Docker Compose command line help, you'll now see this new option here. And it's easy to get confused for me, at least. Confuse the project in the profile. So we've always had project. Project is the current scope. And if you didn't know, when you type a Docker Compose command, it looks in the current directory for a file called Docker Compose YAML, and then it will look up a directory and up a directory and so on until it finds one. And it considers that the project. You can override that. Obviously, you can have

1:14:04 Project Scope and Avoiding Conflicts

1:14:06 a different file name if you want and you specify that with a file name. You can override which directory to use and you can actually override the name of the project. The real quick reason on why you'd ever wanna do that is if you've ever wanted to spin up two of the same thing in the same directory, that's how you can do it is you can override the project name and then it will spin up the same YAML file, but it will use different container names. It'll add basically the project name inside the container name.

1:14:33 That's why when when we all probably didn't realize this, but when you do a Docker Compose PS, you're actually seeing the project name first. That's what the raw code part is. So if I override that with a dash p, it will replace that that value with something else so that they don't conflict. Right? Because we can't have container names that conflict. Now, caveat, if you're hard coding your ports, this will also not work because you'll get the port confliction. But the way you get around that in Dockerfiles is you just don't specify your published port, and then it will randomly

1:15:02 assign you ports that you can use every time, and then it'll make sure they never conflict. So that's a really cool way if you ever wanna spin something twice without having to clone it down twice and all that obnoxious stuff. Alright, so anyway, back to profile. So profile allows another layer inside of the project. So I'm in the project scope. I'm now going to have that profile part. And so if I do a Docker Compose profile log up, it will spin up the ghost. Nice. This profile, I have to specify with every command in order to get

1:15:41 the awareness of those things. Right? So if I don't if I don't type in dash dash profile, then it won't know what ghost is because it won't I think that's true for every command. Someone in someone in chat might I don't if Sujay's still around, but somebody in chat might know wrong know that I'm wrong. But every command I that I'm aware of expects that profile there. So now notice when I do a Docker Compose ps, it's well, actually, no. It is listing Go. So see, I'm already wrong. What I was gonna say was I have

1:16:12 to use Docker Compose dash dash profile blog ps, but it's indeed listing it. So I now that I think about it, that might have been a recent change where they added to the p s command because I've been watching the commits, they they're these new commands that they're doing, especially this new feature, they kinda go back and forth based on feedback. So shout out to Docker, taking community feedback, because if you're if you you can jump on their Slack or in their GitHub issues, and they're they're they really are taking feedback and adding new features to Compose based on

1:16:45 feedback. I've had several of my own features, including adding this healthy statement inside that line there, adding that into the new Compose just because I put in a GitHub issue, and they marked it for development and put it in. I didn't have to actually PR it for them. So we can do that same thing with something like Docker Compose. Let's let's actually see if this works. Docker Compose top ghost. Okay. So see that? Maybe they've now done it so that it knows when I did the up, I did it on a specific profile so the other commands

1:17:16 Demo: Profiles for Utility Tasks (`run`)

1:17:21 are semi aware of it because it didn't used to work this way. Docker Compose exec ghost. Bash. Let me see. Let me do that. Okay. So there you go. That's what I was looking for, is it doesn't see the service ghost because I have to do this. It's a little tedious. There we go. And now I'm inside of my container. So I tend to use this for either teams that are all semi a part of each other's workflow, but they often don't need to start up everything. But I often actually use this more for one off

1:18:05 maybe you wanna install all the packages. Maybe you have a monolithic app and it's Ruby plus NPM plus apt get stuff, and you wanna do a refresh of all the packages or whatever, and you don't wanna have to shell in and then type each thing manually. So what I've seen teams do, a team that I'm working with is doing this, they do write little shell scripts to automate all that, you know, those common developer workflow commands for their environment, and then they just make that something inside of another service. So they might do they might just make something

1:18:39 called, you know, one off, you know, or or maybe update. Then they'll make it a profile update. And then let's say the image we're using is still ghost. And what they really need to do is they're wanting to apply chain you know, assuming we got bind mounts here and we're all talking to the same database, they wanna do maybe a database schema update or they wanna do something that's not necessarily in this container, but they don't wanna shell in and have to type a bunch of commands. So then they can type here command, you know,

1:19:26 whatever. I have to get install ghost. So, yeah, maybe maybe curl. Right? So they could do this. Now what that does that what that means is is when they're in their project, when they just do a normal Docker Compose up, it's never gonna try to run that service. Right? That service is, by default, will not run because it's not in a default profile. So the you know, and default profile means basically everything that's not listed as a profile. And then when I wanna do a run a one off, one of the neat things about this feature

1:20:09 is that it knows if I wanna do a run command or an up command on something and I specify it directly, I don't have to list the profile name. So I can do something like Docker Compose up or just even just run what do I call it? Update. So that was, like, a really short command, Docker Compose run update. And, essentially, what I'm turning this into is a tool for utility commands that I don't wanna have to remember the whole long command that I wanna do, like a schema update or scan with Snyk or Trivy inside of my image and

1:20:52 looking for all of my vulnerabilities. Maybe you don't wanna have to remember all those commands. So now all you really need is an image. It doesn't really matter what image you use. It just needs to be the one you wanna run the tool in. Yep. And then you can override with that command right there, and then it does this actually doesn't matter what profile you call it because we're never going to specify that profile. In this case, we're only gonna run that particular service by name when we wanna do something. So you might have one that says schema

1:21:17 update and another service here that says apt get update or something. And it just it saves you keystrokes, and it honestly, what it will do for your dev team is create a standard around how they do these things. And you can even because you can sort of make this command really ugly, you can avoid shell scripts here as long as you don't have too much complexity by just doing it in the YAML. And now your YAML becomes that single make file universal automation tool for local dev. Okay. So just to clarify, like, the existence of the profile

1:21:45 Value of Profiles for Workflow Automation

1:21:47 is key to move it from the default profile. I mean, and if you run a Docker Compose up right now, we will not get an update. Is that correct? Say that again. If we run Docker Compose up, we shouldn't see the update container run. Right. Because the existence of the profile list means that it's removed from, like, any sort of default profile context. And we also did get a comment from in the chat saying that you can use Compose underscore profiles environment variable. He's always adding value to my streams. Thanks, man. You're my So that's a great that's a great point. You

1:22:30 might even have some developer documentation that says, if you're on this team or if you're working on this, just set this profile value and then all things will be fine. Right? I'm assuming you can use dot ENV for that or well, wait. Dot ENV goes into the Compose file. It's not used by the Compose CLI. Not sure if that's true. Anyway, Compose can consume a dot ENV file if you wanna set environment variables there so you don't have to remember every time in your shell to set it. But, yeah, in fact, there's a whole webpage on

1:23:02 environment variables that the Docker Compose command line can accept, including the profile, the Docker engine to connect to, like all there's a lot of things you can do there and, yeah, Compose Profiles. Great tip. Awesome. Yeah. Those profiles are a long overdue feature that would just remove an entire class of makefails that I've been adding to all my projects over the years. Like, they can just disappear now because I can have profiles for one off tasks and different sets of containers that I need for different purposes. Particularly CI is a really good one where I may wanna run different sets of tests

1:23:35 and use profiles to be able to kinda orchestrate them in a pretty clean way. So Yeah. And if someone's thinking about, well, when can I use this? Because, you know, RC, it's it's Release Client, right, so this new tool isn't truly GA, you can still do all of this with the old I may not be speaking out of turn, but if I do Docker dash Compose because the old Compose tool uses oh, no. It's not profile. Oh, there it is. It's not in alphabetical order. Because what I was getting ready to say is that the profile is a Compose spec feature,

1:23:41 Compatibility and Listing Projects

1:24:19 not a well, it's technically a CLI feature combined with this spec feature, you could argue it either way. But what I was gonna say is that the old I believe that the old Compose traditional Docker Compose traditional tool, I believe that that uses and supports this profile feature, and they I think they've had that for over a year. If we go back in the releases of the Compose Everybody Knows, they converted to the they updated to the Compose spec as their file format at least over a year ago. And so those of you that are not

1:24:56 yet ready to either run a release client or you maybe don't have Docker Desktop and you don't wanna use this release client tool yet because you're worried about bugs or whatever, I would say, you know, the Compose you have now, as long as it's up to date, supports a lot of these things. What it doesn't support is some of the new command line, like, l s command, right, the new the new by the way, we can we can actually do that because now that we have a project. You'll you'll see that it it would, yeah,

1:25:30 it would list and this is across my entire daemon, right, like I was saying. So if it's five other if you got five other directories where you're running stuff, you'll see all of them listed by their project name. If I were to do a Docker since we didn't do any ports, this actually should work. If I do a Docker Compose, project? No. Project name? Project name. It's also dash p, but I like the name in there for everybody so they know what I'm doing. So I just spun up the whole state same thing that we just

1:26:11 did in a duplicate environment, but it's going if I had ports assigned, it it it would conflict, but we don't have ports right now. So now I can do a Docker Compose LS and we can see both of those running. Yeah. I think we need to open an issue against the Compose CLI. So does it list the directory, the Compose files in? Because Oh. Because that's just two projects for me and I just have no idea where those lived. I would Yeah. Or like yeah. Like the the either relative path or these maybe just the full path to where to the

1:26:23 Improving `ls` Output & Internal Labels

1:26:38 Compose file that it used for that project. Right? Yeah. Because because right that's that's the problem right now is come from. Yeah. Yeah. Because I customize it. Now, let me go let me just real quick off screen look at the Docker dashboard and see if it actually because they've been taking a lot of feedback on the GUI as well, and those of us that have been trying to use it are saying, hey. We need this. We need that. So, no, I don't see it showing me an indication of which Compose file. So that's a great idea.

1:27:14 I wouldn't be surprised if that was already in there. Or almost like Docker Compose info, right, that does sort of investigation. Oh, you know what? I wonder if convert I wonder if convert lists it. Convert is a little bit of a new thing. No. It doesn't. Convert is a a kind of a new command. Basically, what it does is it ingests whatever you're giving it and then spits out a consolidated YAML of what it's going to use. So, like, for example, I don't specify a network in our YAML because I just use the default, but this is literal.

1:27:30 Convert

1:27:59 Yeah. So this is kind of like what Docker Docker Compose config, I think, used to be. So if we did Docker dash Compose config, one of the things that it would do is it would spit out oh, and you see how it it automatically, in that old command line, it would spit out a version. It would assume version three dot nine the latest because I didn't specify one. So it's a little bit like that old tool, but it also has other options that are interesting. So if you look at the help of it, it will help you list out things in

1:28:39 a little bit different format. It's a it's a little bit weird to use, but just if you just bear with me for a second. Docker Compose convert services will just list my services. Docker Compose can convert volumes, which I don't have any. So if I do profiles so this might be a part of not that we're trying to run Bash scripts here, but if you wanted to wrap this in other commands, this is kinda one of those things where this would be handy to just spit out the information I need in order to form, an automated way, other Docker Compose commands. So

1:29:15 maybe if you're using Docker Compose in CI and you wanna you wanna find all the services and then check them all or do something like that in an automated way, you could use these as automated responses in command lines. But that's that's really the only reason I can think of using it that way. But wonder if the Compose LS can't list the directories because, I mean, there's no primitive of Compose project, right? I mean, maybe it's just parsing the names of the containers and going, you look like a Compose project, and that's all it really knows.

1:29:45 Right. True. Because a lot of this is dealing with labels, right? So if oh, well, I think I have to do You may have to do a container inspect or something. Yeah. A lot of people there's not actually a lot of magic to Compose, really. It's just really talking to the Docker command line or Docker c l not to the CLI, but the to the API, the Docker engine, and adding labels for all of the things it needs to do to keep track of. So you will see Rawkode. There we go. Right. Yeah. And that is actually the

1:30:27 and I think I mentioned this earlier, but I wanna reiterate, you can use both command lines back and forth. They're designed to be compatible with each other, so you can use a Docker Compose up with the dashed old version and then a Docker Compose down with the new version, so they're completely compatible with each other because they're really just using, for the most part, these same labels to identify the services and the volumes and networks and all that stuff that it needs to know. So it's not like there's a database somewhere or some Compose API that's running as a daemon, and

1:31:01 storage inside of Docker, really, to keep Compose specific things. So it just uses the same labels like we would use in a Kubernetes cluster, really, to do that work. If you're a Swarm of fans, Swarm actually uses, for the stacks, that stack feature really only uses service labels to organize all the objects for stacks. So that's actually how Swarm works as well. It uses different labels. These are actually container labels. In Swarm, it uses different object labels for for the stack to work. But anyway, it's all just metadata. Metadata all the way down. Alright. What else we got, people?

1:31:38 Security, Cloud Deployment (ECS/ACI), and SoloDevOps

1:31:40 Someone else about security. That's a whole separate topic. Yeah. Well, you just asked if we covered any security practices here. I mean, does security come into play? I mean, we're still saying Compose is a tool for local development rather than production. So do we leave security at at the other side of the door for that? Yeah. Because because, again, yeah, like you're saying, like, I don't advocate even though you can technically use Compose on a server for production, I don't I don't ever really advocate its use. I feel like in most cases, we've all moved beyond it.

1:32:11 That being said, with the new Docker Compose deploy, which we didn't even talk about today, but, you know, maybe some other day, have you had people on your show before to talk about the deploy, the AC the ECS and ACI stuff? No. I know you've had some Docker people on recently, so I didn't know if you because Docker Compose there's not a deploy. Right? Yeah. No. It's they haven't changed it. Alright. Haven't used this in a few months. So Docker Compose up, and I can I can point it at a ECS cluster or an ACI instance or other

1:32:47 other types of Docker plug connections? I don't know how you should describe it. Does that coupling of deployment with, like, your database and your app not give you the fear, though? Like, I I I can't see a world where I'd want to use that. I think that's where I get Well, I think the argument that so the reason that Docker's adding all these is that they feel like there's still a really big gap, and you'll see this with Docker Desktop with the new dev workspaces or dev what are they called? Have to look it up already. Dev environments is what they're calling

1:33:20 it, which, like, a different topic altogether. But what we're seeing is that Docker is trying to solve developer problems, not production problems. Right? So I would argue that this Docker Compose up towards ECS or ACI or, you know, I've been asking them to do a Digital Ocean one and some of the other non major clouds. Know that they would like to do a Google one as well. They argue that maybe this is really for the one person shops, right, where you're just like the solo DevOps person and you simply can't use those other tools because of

1:33:57 their complexity and you don't have enough time, and so this is good enough. And also, a lot of times, developers need to share what they're working on or just literally just test something on a server somewhere that's outside their machine. I actually was just working with a developer yesterday that his he had a '20 '18 MacBook, and he couldn't spin up in Docker locally his the the environment that he needed to test the app because it required 16 gig of RAM for everything to work and to run all the r specs because there was, like, 90,000 r specs or something.

1:34:28 So they needed a server to run it on, and there's not really any deep, easy integration in a lot of these tools to just say, hey, create me an instance on the cloud, put my stuff on it, run it there for a minute. And I think that's what they're doing. Now, will people use that for production? Sure. People always use dev tooling for production when they shouldn't. But I think there's a I think there's room, right? There's room for us to have this tooling. What I do hope is that they communicate well about the the goal and intent of these tools,

1:34:59 not, hey. Look. We have this new way to deploy ECS. You should totally use this all day for production. Right? Because they don't always like, the messaging is sometimes lost in, hey. Look at the new thing we did, and people assume that you say, oh, well, said ECS, so you must mean your production workflows. Yeah. I hadn't really thought about it through that lens. But, you know, people if you're using managed services for one from AWS and you just need to get your dev environment into that environment, then that's actually a really good way of of doing it. And I

1:35:25 just hadn't really given that a lot of thought. Yeah. But maybe that would work. I mean, still a whole bunch of other concerns around the authorization and the IAM policies to speak to those managed overseas. For a very crude development environment that's in the cloud, yeah. Okay. Yeah. That would work. Think for the same thing, like, the same what was the same thing was happening with Docker Machine. People were using Docker Machine to spin up production servers. And I and I probably was quoted, and you probably could have found a video of me from somewhere

1:35:52 circa 2018 saying, hey, look, because I appeal to the solo DevOps, to the solo developer, right? Whenever I do a talk at a big conference, I always try to get a one of the things I do survey is how many people here are responsible for their DevOps, and they're the only one that is doing that in the team, essentially what I call SoloDevOps. A quarter of the room raises their hands, right? So there's this huge need that's not the majority, but an untapped need for we don't need at scale. In fact, if I were to put on a t shirt

1:36:23 from Pulp Fiction that says, say at scale one more time, the the famous line I'm forgetting his name now. Samuel L. Jackson's character. He says, something one more time, and it's to say at scale one more time on the Internet because there's definitely a lot of tools out there that are focused on large infrastructure, hundreds or thousands of containers, but there are definitely lots of teams where there's one person, maybe two, they need a dozen servers, maybe 20 servers, and they just don't need the inherent complexity that comes with implementing Terraform, Ansible, Argo CD, GitHub Actions, and this huge tech

1:37:00 Closing

1:37:03 stack for I want to run some containers on servers for a while. So I appeal to those people. Yeah. Okay. We've ran a little bit over, so I'm gonna pop us back over to here. Sorry. Do you have anything else you want to shore shore? No. That's it. I mean, we could talk forever, so we have to cut it off at some point. Yeah. I'll leave you with the I'm here to answer questions, so if people have more questions, you know. Yeah. We'll we'll take one more question. If any more slip in, we'll do our best to answer

1:37:31 them. But asked, is this still in beta, the ECS thing? Because he says that he has to enable some sort of beta Docker thingy to get that to work. Is that the case? I don't know. If Sujay's still in the chat, he might know more. I would say, as far as I know, it is still pre general availability, pre GA, prerelease. I am assuming that they're tying the version, because right now we're on, like, RC something of the actual Docker Compose command line tool, and that is that plugin is what's needed in order to deploy to these contexts.

1:37:34 Compose Contexts and GA Status

1:38:13 And we didn't get into context, but that's what we're talking You change your context from your local Docker engine to ECS or to ACI, and then you can use Docker Compose up to deploy to those contexts, similar to Kubernetes Kube control context. And as I'm assuming that they're tying those features to the version of the Compose CLI since they're bundled in with it. And since it is not GA, I will assume that they are also not GA. But that's a lot of assumptions. Don't quote me on that. Alright. Well, that was an awesome feature pad

1:38:47 session. It was really good to get a look at that and just see how the profiles work and see how cool that Compose CLI is is coming along. I'm really excited with that, and I'm looking forward to actually, like I said, removing a whole bunch of make files in Bash scripts. I have so many of them scattered across so many projects that that one simple profile feature just removes all. That's really exciting to me. It's yeah. I have the same way in the same way I was using something called Docker app, which is really not anymore anymore a

1:39:15 thing. They're they're deprecating that as well. But there was this idea for a while about formalizing a lot of the the tooling and versioning around Compose files into something that was called Docker App. And one the offshoots of that is that it could kinda dynamically create Compose files on the fly from other templates, and this profile thing basically saves me from all of that. It saves me from having to try to wrap around that. Another Docker captain was actually working on all of that stuff too, trying to formalize a tool that would allow us to

1:39:48 basically solve the templating needs of complex teams that need to use Compose for development environments, but not always spin everything up all the time. And, yeah, that profile feature, definitely. You know, I'm sure there's more things we could add to it, but I think that really helps. I I should do a plug for you and my you and me as well. For those of you that are in chat, if you didn't get your questions answered, we both have Discords. So, you know, I'm in his Discord. I think he's in mine. I'm not sure. So just find us in Discord if you

1:40:15 have questions later or on Twitter. We're both on Twitter. If we don't get your questions answered, don't worry. We're not going anywhere. Because, you know, we live on the Internet, so I'm I'm available after this live show. Yeah. We're both very active on Twitter. Our handles are on the screen. We both do have Discords. We're active there too. And in fact, we pulled through a lot of your announcements into our channel as well. So sharing sharing the the love and the knowledge as much as we can. So alright, Brent. I to a I need to

1:40:42 have a zap for you. I need to have a zap for you. I need to figure that out later. Yeah. Because I'd love to have that more of that stuff in some of my Twitter channels too, so we'll talk about that later. Awesome. Well, thank you so much for joining me today, for guiding us through this. Just so much value in the conversation as well. You just shared so much insights there about how people are using this tool. Definitely go check out Brett's courses. Keep learning, and thank you again. Brett, have a wonderful day, and I'll I'll see you

1:41:08 soon. Yeah. See you all.