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