‫What is the best strategy to delay your containers in order to keep them on a specific order like doing
‫D.B. Webb rabbit and so on.
‫So the number one thing is this isn't even a dev OP saying this is a distributed computing thing is
‫it.
‫I'm assuming you're talking about production not local development workflow with something like Docker
‫compose.
‫But you're talking about production all your apps have to be able to fail or retry.
‫So the entire like whether or not this is before Docker basically whatever you're using there it has
‫to recover in some fashion from not being able to talk to other services outside of its own.
‫And this is a core principle of distributed computing.
‫In fact if you look up what a resource would be here is 12 factor twelve factor dot net is sort of a
‫it's a decade old set of principles around the mindset of cloud native and distributed computing those
‫are two different but similar types of things that really it's about if I've got a bunch of servers
‫or a bunch of things that my servers have to talk to how do I or orchestrate all of those to be available
‫when they're needing to be available.
‫And the answer is you can't control startup right because startup is only a part of the problem.
‫When you have to replace a container if the other containers lose connection from it because a container
‫or any other service goes down for a second all those other services that are using it have to be to
‫recover.
‫And so unlike the old days where we had a single server and we put the database in the website on the
‫same server and that was always available and online until it went down that was easy.
‫But now in this world we have distribute computing your containers and all of your services have to
‫take that in mind.
‫So they either need to have a retry which if you're doing development most develop sorry.
‫Most database drivers all have built in retry designed in them so they will actually retry to you know
‫like Mongo D.B. and node.js actually even has a buffer protocol where it can't connect it'll hold the
‫commands for a little bit to wait for the database to come back online.
‫It's just built into the driver for your developing language so there's lots of stuff out there like
‫that.
‫And if if your app doesn't do anything like that then and it just fails.
‫The nice thing if you're using container orchestration is that part of that job of that orchestrator
‫is if the container just crashes because it loses connection from something then the orchestrator will
‫restart it will basically start a new copy of that somewhere else.
‫And that's one way to recover from failure.
‫It's a little bit cleaner and less taxing on your systems if they just retry but another way in Docker
‫to do it is to just let your apps crash essentially and then Docker will restart them based on your
‫settings.
‫So I know that's probably not the little click button.
‫Answer a lot.
‫People might just answer Oh you need to add retry to your doctor compose or something but that's not
‫a production solution because it only has to do that only has to do with original startup and if you
‫even google for something like Wait for it scripts those don't really solve the whole problem either
‫because you're going to one of the things is if you're going to start using containers you're going
‫to be updating them more often that's part of the progress of implementing the dev ops mindset is things
‫are going to be updated more often than they were in the past because that's one of the core tenants
‫of dev ops is continually evolving and improving.
‫So when you start doing that that means that any one piece of your puzzle has to be able to handle any
‫other piece of the puzzle going down and you can't really do that with startup order if you know what
‫I mean.
‫Hopefully that helps.
‫It's it's a tough problem to solve if you're dealing with legacy apps but it's a continuum.
‫You have to continually work on continuing on the process of getting your apps all handle failure.
‫Essentially it's not an easy problem innit.
‫It's a it's a process to go through.