Is Docker speelgoed of niet? Of is het nog steeds waar?

Hallo iedereen!

Ik wil echt meteen op het onderwerp ingaan, maar het zou juister zijn om iets over mijn verhaal te vertellen:

Toegang

Ik ben een programmeur met ervaring in het ontwikkelen van frontend single page applicaties, scala/java en nodejs op de server.

Een hele tijd (zeker een paar of drie jaar) was ik van mening dat Docker manna uit de hemel is en over het algemeen een erg coole tool en absoluut elke ontwikkelaar zou het moeten kunnen gebruiken. En hieruit volgt dat elke ontwikkelaar Docker op zijn lokale computer geïnstalleerd zou moeten hebben. Hoe zit het met mijn mening, kijk eens tussen de vacatures die op dezelfde hh staan. Elke tweede bevat een vermelding van docker, en als je deze bezit, zal dit je concurrentievoordeel zijn 😉

Onderweg ontmoette ik veel mensen, met hun verschillende houdingen ten opzichte van Docker en zijn ecosysteem. Sommigen zeiden dat dit handig is en platformonafhankelijke functionaliteit garandeert. De tweede begreep niet waarom ze in containers moesten draaien en welke winst eruit zou komen, de derde kon het helemaal niets schelen en maakte zich geen zorgen (ze schreven gewoon de code en gingen naar huis - ik benijd ze, door de manier :)

Redenen voor gebruik

Waarom heb ik docker gebruikt? Waarschijnlijk om de volgende redenen:

• databaselancering, 99% van de applicaties gebruikt ze
• lancering van nginx voor frontend-distributie en proxying naar backend
• je kunt de applicatie in een docker-image verpakken, op deze manier zal mijn applicatie werken waar docker ook bestaat, het distributieprobleem is onmiddellijk opgelost
• service-detectie out-of-the-box, u kunt microservices maken, elke container (verbonden met een gemeenschappelijk netwerk) kan gemakkelijk een andere container bereiken via een alias, erg handig
• Het is leuk om een ​​container te maken en erin te ‘spelen’.

Wat ik altijd NIET leuk vind aan docker:

• Om mijn applicatie te laten werken, heb ik Docker zelf op de server nodig. Waarom heb ik dit nodig als mijn applicaties op jre of nodejs draaien en de omgeving daarvoor al op de server staat?
• als ik mijn (privé) lokaal gebouwde image op een externe server wil draaien, dan heb ik mijn eigen docker-repository nodig, heb ik het register nodig om ergens te werken en moet ik ook https configureren, omdat docker cli alleen via https werkt. Oh verdomd... er zijn natuurlijk opties om de afbeelding lokaal op te slaan via docker save en stuur de afbeelding gewoon via scp... Maar dat zijn veel lichaamsbewegingen. En bovendien lijkt het een ‘kruk’-oplossing totdat je eigen repository verschijnt
• docker-compose. Het is alleen nodig om containers uit te voeren. Dat is alles. Hij kan niets anders doen. Docker-compose heeft een aantal versies van zijn bestanden, zijn eigen syntaxis. Hoe declaratief het ook is, ik wil hun documentatie niet lezen. Ik heb het nergens anders nodig.
• wanneer ze in een team werken, schrijven de meeste mensen een Docker-bestand erg scheef, begrijpen niet hoe het in de cache wordt opgeslagen, voegen alles wat ze nodig hebben en niet nodig hebben toe aan de afbeelding, erven van afbeeldingen die niet in Dockerhub of een privérepository staan, maken er enkele docker-compose bestanden met databases en niets blijft bestaan. Tegelijkertijd verklaren de ontwikkelaars trots dat Docker cool is, voor hen alles lokaal werkt, en HR schrijft belangrijk in de vacature: “Wij gebruiken Docker en we hebben een kandidaat nodig met zulke werkervaring.”
• Ik word voortdurend achtervolgd door gedachten over het verhogen van alles in Docker: postgresql, kafka, redis. Het is jammer dat niet alles in containers werkt, niet alles is eenvoudig te configureren en uit te voeren. Dit wordt ondersteund door externe ontwikkelaars, en niet door de leveranciers zelf. En trouwens, de vraag rijst meteen: leveranciers maken zich geen zorgen over het onderhouden van hun producten in Docker, hoe komt dit, misschien weten ze iets?
• De vraag rijst altijd over de persistentie van containerdata. en dan denk je: moet ik gewoon de hostmap mounten of een dockervolume maken of een datacontainer maken die nu is deprecated? Als ik een map aankoppel, moet ik ervoor zorgen dat de uid en gid van de gebruiker in de container overeenkomen met de id van de gebruiker die de container heeft gestart, anders worden de bestanden die door de container zijn gemaakt met rootrechten gemaakt. Als ik gebruik volume dan worden de gegevens in sommige eenvoudigweg aangemaakt /usr/* en er zal hetzelfde verhaal zijn met uid en gid als in het eerste geval. Als u een component van derden lanceert, moet u de documentatie lezen en zoeken naar het antwoord op de vraag: "in welke containermappen schrijft de component bestanden?"

Ik vond het altijd niet leuk dat ik te lang met Docker moest sleutelen in de beginfase: Ik ontdekte hoe ik containers moest starten, van welke afbeeldingen ik moest starten, maakte Makefiles die aliassen bevatten voor lange Docker-opdrachten. Ik haatte docker-compose omdat ik geen ander hulpmiddel in het docker-ecosysteem wilde leren. EN docker-compose up Het stoorde me, vooral als ze elkaar daar nog ontmoetten build constructies, in plaats van reeds samengestelde afbeeldingen. Het enige wat ik echt wilde, was efficiënt en snel een product maken. Maar ik kon er niet achter komen hoe ik Docker moest gebruiken.

Maak kennis met Ansible

Onlangs (drie maanden geleden) werkte ik met een DevOps-team, waarvan bijna alle leden een negatieve houding ten opzichte van Docker hadden. Om redenen:

• docker regels iptables (hoewel je dit kunt uitschakelen in daemon.json)
• docker bevat fouten en we zullen het niet in productie uitvoeren
• als de docker-daemon crasht, crashen alle containers met infrastructuur dienovereenkomstig
• geen docker nodig
• waarom docker als er Ansible en virtuele machines zijn

Bij dezelfde baan maakte ik kennis met een andere tool: Ansible. Ik heb er ooit over gehoord, maar ik heb niet geprobeerd mijn eigen draaiboeken te schrijven. En nu begon ik mijn taken te schrijven en toen veranderde mijn visie compleet! Omdat ik me realiseerde: Ansible heeft modules voor het uitvoeren van dezelfde docker-containers, image-builds, netwerken, enz., en containers kunnen niet alleen lokaal worden uitgevoerd, maar ook op externe servers! Mijn vreugde kende geen grenzen - ik vond een NORMAAL hulpmiddel en gooide mijn Makefile- en docker-compose-bestanden weg, ze werden vervangen door yaml-taken. De code is gereduceerd door constructies als loop, when, Etc.

Docker voor het uitvoeren van componenten van derden, zoals databases

Ik heb onlangs kennis gemaakt met ssh-tunnels. Het bleek dat het heel eenvoudig is om de poort van een externe server door te sturen naar een lokale poort. De externe server kan een machine in de cloud zijn of een virtuele machine die in VirtualBox draait. Als mijn collega of ik een database (of een ander onderdeel van een derde partij) nodig hebben, kunnen we eenvoudig de server met dit onderdeel starten en uitschakelen wanneer de server niet nodig is. Port forwarding geeft hetzelfde effect als een database die in een docker-container draait.

Deze opdracht stuurt mijn lokale poort door naar een externe server waarop postgresql draait:

ssh -L 9000:localhost:5432 [e-mail beveiligd]

Het gebruik van een externe server lost het probleem met teamontwikkeling op. Zo'n server kan door meerdere ontwikkelaars tegelijk worden gebruikt; ze hoeven postgresql niet te kunnen configureren, Docker en andere fijne kneepjes te begrijpen. Op een externe server kunt u dezelfde database in Docker zelf installeren, als het lastig is om een ​​specifieke versie te installeren. Het enige wat ontwikkelaars nodig hebben is het bieden van ssh-toegang!

Ik heb onlangs gelezen dat SSH-tunnels een beperkte functionaliteit zijn van een reguliere VPN! U kunt eenvoudig OpenVPN of andere VPN-implementaties installeren, de infrastructuur opzetten en deze voor gebruik aan ontwikkelaars geven. Dit is zo cool!

Gelukkig geven AWS, GoogleCloud en anderen je een jaar gratis gebruik, dus maak er gebruik van! Ze zijn goedkoop als je ze uitschakelt wanneer je ze niet gebruikt. Ik heb me altijd afgevraagd waarom ik een externe server zoals gcloud nodig zou hebben, het lijkt erop dat ik ze heb gevonden.

Als lokale virtuele machine kunt u dezelfde Alpine gebruiken, die actief wordt gebruikt in docker-containers. Nou ja, of een andere lichtgewicht distributie om de machine sneller te laten opstarten.

Kort gezegd: u kunt en moet databases en andere infrastructuur-goodies uitvoeren op externe servers of in virtualbox. Ik heb geen docker nodig voor deze doeleinden.

Een beetje over docker-images en distributie

Ik schreef al статью waarin ik wilde overbrengen dat het gebruik van docker-images geen enkele garantie biedt. Docker-images zijn alleen nodig om een ​​docker-container te maken. Als u een upgrade uitvoert naar een docker-image, voert u een upgrade uit om docker-containers te gebruiken en gebruikt u deze alleen.

Heb je ergens gezien waar softwareontwikkelaars hun producten alleen in een docker-image porten?
Het resultaat van de meeste producten zijn binaire bestanden voor een specifiek platform; ze worden eenvoudigweg toegevoegd aan de docker-image, die wordt overgenomen van het gewenste platform. Heb je je ooit afgevraagd waarom er zoveel vergelijkbare afbeeldingen op dockerhub staan? Voer bijvoorbeeld nginx in, je ziet 100500 afbeeldingen van verschillende mensen. Deze mensen hebben nginx niet zelf ontwikkeld, ze hebben eenvoudigweg officiële nginx aan hun docker-image toegevoegd en deze voorzien van hun eigen configuraties voor het gemak van het lanceren van containers.

Over het algemeen kun je het eenvoudig in tgz opslaan, als iemand het in docker moet uitvoeren, laat hem/haar dan tgz toevoegen aan het Docker-bestand, overerven van de gewenste omgeving en extra buns maken die de applicatie zelf in tgz niet veranderen. Iedereen die een docker-image gaat maken, weet wat tgz is en wat hij nodig heeft om te werken. Dit is hoe ik docker gebruik hier

Kortom: ik heb geen docker-register nodig, ik gebruik een soort S3 of gewoon bestandsopslag zoals Google Drive/dropbox

Docker in CI

Alle bedrijven waar ik voor heb gewerkt zijn vergelijkbaar. Meestal zijn het boodschappen. Dat wil zeggen, ze hebben één applicatie, één technologiestapel (nou ja, misschien een paar of drie programmeertalen).

Deze bedrijven gebruiken docker op hun servers waar het CI-proces draait. Vraag: Waarom moet u projecten in een docker-container op uw servers bouwen? Waarom bereidt u niet gewoon een omgeving voor de build voor, bijvoorbeeld door een Ansible-playbook te schrijven dat de benodigde versies van nodejs, php, jdk zal installeren, ssh-sleutels zal kopiëren, enz. naar de server waarop de build zal plaatsvinden?

Nu begrijp ik dat dit mezelf in de voet schiet, omdat docker met zijn isolement geen enkele winst oplevert. Problemen die ik tegenkwam met CI in docker:

• opnieuw heb je een docker-image nodig om te bouwen. je moet naar een afbeelding zoeken of je eigen dockerbestand schrijven.
• 90% dat je enkele ssh-sleutels moet doorsturen, geheime gegevens die je niet naar de docker-image wilt schrijven.
• de container wordt gemaakt en sterft, alle caches gaan ermee verloren. bij de volgende build worden alle projectafhankelijkheden opnieuw gedownload, wat tijdrovend en ineffectief is, en tijd is geld.

Ontwikkelaars bouwen geen projecten in docker-containers (ik was ooit zo'n fan, echt waar, ik heb in het verleden medelijden met mezelf xD). In Java is het mogelijk om meerdere versies te hebben en deze met één commando te veranderen naar degene die je nu nodig hebt. Het is hetzelfde in nodejs, er is nvm.

Uitgang

Ik geloof dat docker een zeer krachtige en flexibele tool is, dit is het nadeel (klinkt vreemd, ja). Met de hulp kunnen bedrijven er gemakkelijk aan verslaafd raken en het gebruiken waar dat nodig is en niet. Ontwikkelaars lanceren hun containers en een aantal van hun omgevingen, waarna het allemaal soepel overgaat in CI en productie. Het DevOps-team schrijft een soort code om deze containers uit te voeren.

Gebruik docker alleen aan het meest recente fase in uw workflow, sleep deze dan niet aan het begin naar het project. Het zal uw zakelijke problemen niet oplossen. Hij zal de problemen alleen naar een ANDER niveau verplaatsen en zijn eigen oplossingen aanbieden, jij zult dubbel werk doen.

Wanneer docker nodig is: Ik kwam tot de conclusie dat docker erg goed is in het optimaliseren van een bepaald proces, maar niet in het bouwen van basisfunctionaliteit

Als u toch besluit docker te gebruiken, dan:

• wees uiterst voorzichtig
• dwing ontwikkelaars niet om docker te gebruiken
• lokaliseer het gebruik ervan op één plaats, verspreid het niet over alle Dockefile- en docker-compose-opslagplaatsen

PS:

• Kwam ik onlangs tegen packer en ze zeggen dat het heel goed werkt met Ansible en je in staat stelt het proces van het bouwen van afbeeldingen (inclusief docker-image) te verenigen
• ook over docker, interessant artikel

Bedankt voor het lezen, ik wens u transparante beslissingen in uw zaken en productieve werkdagen!

Bron: www.habr.com