‫So
‫we're going to go fast.
‫All right.
‫Then we're going to end the show because we're past our hour.
‫I want to get you guys some feedback.
‫All right.
‫The first one up is Jacob.
‫There's a whole lot of documentation here. I love documentation Dockerfiles by the way.
‫It's totally fine to put as much as you want.
‫This is actually a YAML file so now we're talking about Compose. Documentation in Dockerfiles or
‫Compose files. Either way.
‫Always a good thing.
‫All right.
‫So he's using a version 3.0 7 which means it's probably for Swarm or something in production like
‫Kubernetes using the Compose on Kubernetes feature set.
‫He's using the official Elastic images from the Elastic there.
‫Let's see you've got your healthcheck.
‫Fantastic.
‫You've got healthchecks. That's great. You've got configs.
‫That's great.
‫You're setting it on a specific network and you're doing host mode on the port
‫so you're giving this direct access to the NIC instead of going through the overlay networks and the
‫routing mesh.
‫That's good.
‫Then, let's see.
‫We've got to deploy down here.
‫Oh, and you're doing endpoint mode DNS round robin.
‫Kudos to you.
‫This is something that a lot of people don't realize.
‫Whenever you're running something in Swarm and you want to disable the virtual IP that sits in front
‫of every overlay service, you want to do that for databases where you only have one node, right, which
‫is a lot of times even if you're doing a mirror of a database you're usually running each one of those
‫in their own service.
‫So there's one instance in a service and that that task of that instance of a container, you don't
‫usually want that virtual IP in front of it because it's now an extra hop. It's another NAT translation.
‫It's more potential problems.
‫If you set endpoint mode to DNS round robin here, that effectively turns off the VIP and has direct
‫access to that container.
‫Kudos to you.
‫I don't see that very often because people don't catch that one. You're also using replicas
‫too.
‫Resource limits of 4G for a gig that's great.
‫Always I recommend always setting resource limits and reservations if you can because that's going to
‫help things all get along inside your cluster.
‫Yeah.
‫Looks like it's running on Docker Swarm. Sweet.
‫Coordination
‫Master.
‫All right.
‫More of the same.
‫Good stuff. Good stuff.
‫You're bind mounting a volume. You're not bind mounting. You're using a named volume.
‫You've got placement constraints here so you're putting this on a node that is hard coded to a specific
‫name. You know you want this one to run on that node only.
‫Of course, the weakness here is that if that node goes down, it won't be able to place it anywhere
‫else.
‫Hopefully you've taken that into consideration.
‫All right.
‫Master2, so that's how you're doing this.
‫It looks like you have master1, master2 hard coded in as separate services and master3. A
‫lot of people have to do it this way that when you have a multi-node database cluster, it's usually easier
‫to put each one of these as their own service.
‫So you've done that. It would be nice if we could just make one service with three replicas.
‫You can find that with some examples using the autopilot pattern. If you look up autopilot pattern IO,
‫or if you just Google your database technology with the word autopilot, sometimes you can find configurations
‫and automation scripts that will help you do it all in one service.
‫There's pros and cons to each.
‫I personally tend to just do it the way you're doing it.
‫I feel like it's simpler even though it's more YAML and it's a little bit more verbose.
‫One thing you could do here.
‫One huge improvement is if these are all all the same parts here.
‫Right.
‫All the same stuff, you can template that, shorten this file significantly by only putting that in a template
‫block.
‫I talk more about that in this...
‫This right here, Jacob. I'll put this in chat.
‫This is three different advanced Docker Compose features that a lot people don't use.
‫One of them is on templating.
‫So if you see the example here, you can you can throw the templating right there.
‫Basically what you're saying is this is what I want in the template
‫and this is where I want you to put it, over and over in each image, or in each service rather.
‫So, a lot of that boilerplate stuff, like you could template the whole thing or you could just template
‫parts of them and have multiple templates, and Docker has documentation on that.
‫That would help make your file smaller and we call it dry.
‫Right.
‫Doing things once. Don't repeat yourself.
‫D R Y
‫You could do that.
‫That would help you alleviate a lot of this repetitive stuff especially around the healthchecks
‫and the deployment stuff.
‫Then you've got your data nodes. Everything's looking good there. You're using your healthchecks. You've
‫got your network set. Your volumes. Let me go down past some of this. You're hard coding stuff to each
‫node. I really wish
‫that we had a way to tell it don't run...like here's a placement constraint.
‫Don't run it on one
‫that is where the other ones run.
‫There's some hope for you. There's two things you can do here. You can look at placement preferences.
‫If you have your different nodes in availability zones and you simply want your database to make
‫sure that it has one copy in each availability zone, like an AWS or something, then you can add labels
‫to each node. Then you just go in here and say I would prefer you to spread these out over my label.
‫You just give it a label and a placement preference instead of a constraint, will allow it to put
‫those on the different servers in the different zones.
‫But the cool thing here is if one zone, or one server, goes down, it will still be able to reassign that
‫somewhere else.
‫Now the worst case here is that two of these are running on the same server but that's probably not
‫so bad if you're able to...I mean one thing might be the data getting the data from one zone over the
‫other. Once you've solved some of those problems.
‫Yeah.
‫Yeah. You're saying, so I can use constraint and allowed to lose one of the physical nodes.
‫Yeah.
‫The thing here is you're you're making it a little bit more brittle by assigning it to Node host
‫names. You have to those specific hosts up. Ideally, like if you're in AWS or something
‫where you can have your servers auto create.
‫So, if a server dies it all creates a new one.
‫Yeah.
‫If you've accounted for all that, great. There's nothing wrong with placement constraints in this way.
‫It just means that those nodes have to be there or those containers die.
‫The other thing is there is a new feature coming in 19.03 and the way you learn about these new features
‫is if you go to Docker on github and you go to Docker-ce releases. I will post this in chat and you
‫can look up new Swarm features. There is a new Swarm feature version that will allow you
‫to run replicas but tell it never run more than X of these replicas on the same node. Super cool feature
‫and helps people ensure that their databases don't all get assigned the same node. You might want
‫to check that out as a more flexible way to ensure they're not on the same note.
‫I think if I scroll down down to Swarm.
‫Yeah. Added support for maximum replicas per node. That's a new feature in the forthcoming 19.03 release
‫that's already in prerelease now so we should be seeing this within the next few weeks or months.
‫You can check that out.
‫That might help you with the constraints.
‫All right.
‫I want to move ahead a little bit.
‫Sorry I can't review all this. I'm moving it down at the bottom.
‫You got your networks, attachable true and proxy.
‫All looks good there.
‫You got volume so you're using the default volume driver so that that way that means that all of this
‫data is stuck on the node that it's on.
‫If you have any shared storage, you might consider REX-Ray or another volume driver so that you can get
‫that storage off that disk. That way, when one of the nodes fails and it wants to create that somewhere
‫else, it will reattach that database volume
‫on the other node.
‫All right.
‫You may have already looked at that. You've got traefik certificates. I could talk about that for
‫a while but we're going to run out of time. I'll leave the traffic certificate stuff for another
‫day. Then you've got configs and other files.
‫This is great. Using all the configs.
‫As you should.
‫I don't see Secrets in here. I'm assuming at some point you're doing to need Secrets and you might need
‫to store those in Secret somewhere. Other than that great YAML. Definitely one of the better ones I've
‫seen.
‫I think there's very little to do here.
‫I think in terms of making it sort of using all the perfect features. The templating is a thing. Considering
‫different volume drivers and considering the new feature. If not placement preferences, the new feature
‫for max replicas per node.
‫Thanks for watching.
‫You can click SUBSCRIBE AND the notification bell to get an alert when I go live so you can join and
‫ask your Devops and Docker questions.
‫You can watch some of my other videos over there and you can do what I'm about to do and just go take
‫a nap.