‫Verificatie of is terug.
‫Wat is uw mening over het gebruik van supervisor D.
‫Dus dat is een geweldige vraag.
‫Supervisor D Ik ga ervan uit dat je supervisor in de container plaatst en deze uitvoert
‫als de PID of het rootproces in die container.
‫Dat is prima als je het goed moet doen.
‫Ik weet dat de beste werkwijzen van Docker nooit meer dan één app per container zijn.
‫En ik vind het leuk om dat idee bloot te leggen en te zeggen dat het echt nooit meer dan één zorg per container is.
‫En wanneer in sommige gevallen die zorg meerdere uitvoerbaar kan zijn.
‫En dus zou je die met iets anders moeten beginnen.
‫En het kan een soort fancy shell-scripting zijn.
‫Ik gebruik graag supervisor D.
‫Als je naar mijn HP-repo kijkt, zie ik dat ik een vreselijk verouderde P HP-repo voor niveau heb, dus ik heb zeker wat updates nodig om enkele van de moderne nieuwe Docker-functies te
‫gebruiken, maar het pronkt met een aantal dingen die uniek zijn en een
‫daarvan is dat voor PDP wanneer je NPM gebruikt, je het PDP-uitvoerbare bestand moet laten draaien en het uitvoerbare bestand van engine X moet draaien
‫en je zou die in afzonderlijke containers kunnen uitvoeren en dat zou waarschijnlijk de officiële Docker-manier zijn
‫om het te doen.
‫Als u hun richtlijnen zou volgen, maar hun richtlijnen zijn gewoon dat ze net als de beste praktijken zijn.
‫Ze zijn de plek om te beginnen, maar dat betekent niet dat je daar moet blijven als je weet wat je doet en
‫waarom je het doet.
‫Dus in mijn geval zou ik in dit specifieke voorbeeld zowel engine X als de p HP FGM combineren in dezelfde container-image en ik voer
‫ze allebei uit met supervisor D en dus voegt het een extra laag complexiteit toe, want nu heb ik Docker met een
‫container die is eigenlijk lopende supervisor als supervisors die motor X en FGM
‫runnen, maar ik merk dat het goed werkt en ik heb gerend.
‫Ik heb dit uitgevoerd op zeer grote wereldwijde websites die in veel regio's actief zijn en misbruik maken.
‫Dit ontwerp is dus zeker in de tijd getest en wordt gebruikt in zwaar zware scenario's.
‫De reden dat ik dit leuk vind, is omdat Docker en swarm out of the box niet het concept van een pod hebben.
‫Als je in de wereld van Cuba en de jaren 80 bent, heb je een pod-concept en in
‫dat geval zou je de motor X en de PSP naast elkaar kunnen laten draaien in hun eigen containers in dezelfde pod en die pod wordt samen ingezet.
‫Dus als het op een server wordt geïmplementeerd, zou je weten dat je beide zou krijgen en dan zouden
‫ze allebei de sockets kunnen gebruiken als je bekend bent met dit spul en PSP ze gebruiken de sockets om
‫heen en weer te praten en dat is zeer efficiënt maar in de Docker Swarm-manier zou je het van de doos doen, op die manier zou
‫je over TGP moeten praten en dat voegt veel vertraging toe.
‫Ik bedoel dat veel vertraging voor sommige mensen misschien goed is, maar als je het hebt over over de
‫server gaan in plaats van alleen over een lokale socket in dezelfde kernel te praten, is er zeker toegevoegd
‫dat je mogelijk meerdere milliseconden, zo niet tientallen milliseconden vertraging daar kent .
‫Dus ik vind het leuk om ze allebei in dezelfde container uit te voeren en ik gebruik supervisor D om dat te doen.
‫Kijk dus eens naar dat voorbeeld.
‫Ik zal dat in de chat gooien.
‫Volgens mij heb ik iemand dat daar al zien posten.
‫Dus hopelijk helpt dat je op weg en beantwoordt dat je vraag.
‫Er zijn trouwens maar een paar plaatsen waar ik supervisor D gebruik en dat is er één van.
‫De andere zou kunnen zijn als koude fusie omdat het ook een patch of iets aan de voorkant nodig
‫heeft om te werken of om Gen-X te bereiken.
‫Dus wanneer je iets hebt waar je een back in binary hebt die naar Amul moet rennen om je code
‫uit te voeren en dan heb je een soort webserver ervoor nodig en ze moeten
‫allebei samenwerken om de service te leveren totaal omdat ze altijd samen worden ingezet en het een niet zonder
‫het ander kan.
‫Het is volkomen logisch dat ze in dat geval samengaan in dezelfde afbeelding, vooral als je ze schaalt, als
‫je ze altijd één voor één gaat schalen, want veel dingen met containers die je anders zou willen
‫schalen, toch? schaal het aantal API is anders u gaat het
‫aantal databasecontainer schalen.
‫Dus in die gevallen heb je zeker de flexibiliteit en wil je bouwen om ze apart bij te werken.
‫In dit geval ga ik de app gewoon tegelijkertijd updaten en ik ga altijd de containers tegelijkertijd vervangen,
‫dus het heeft veel zin om die samen te doen, dus hopelijk helpt dat.