‫Voorwaarde voor dit college is dat je weet hoe je een container moet starten uit eerdere colleges.
‫We zijn net klaar met de laatste lezing over het van buitenaf zien wat er in een container gebeurt.
‫Dit gaat allemaal over in een container stappen om met de binnenkant te rommelen. Er zijn een paar commando's die we
‫kunnen gebruiken.
‫De eerste is een containerrun met een -it.
‫We zullen het hebben over hoe de -it werkt om daadwerkelijk een shell in de container te krijgen.
‫Voor het uitvoeren van containers waarvoor u een tweede proces wilt uitvoeren, kunt u ook de container exec
‫gebruiken, en we zullen daar verschillende voorbeelden van laten zien.
‫Onderweg zullen we een paar verschillen noemen tussen een gewone Linux-distributie, zoals Ubuntu, voor
‫installatie op een virtuele machine of op hardware.
‫En dan hoe die Linux-distributies eruit zien in een container.
‫Laten we beginnen.
‫Van buitenaf in een container kijken is soms erg handig.
‫Maar een van de eerste vragen die mensen me vaak stellen, is hoe ik in de container kom en
‫er daadwerkelijk dingen in doe, live vanaf de opdrachtregel.
‫Soms verwarren mensen dit met het willen hebben van een SSH-server in hun container, zodat ze erin
‫kunnen ssh-en.
‫Maar dat hoeven we eigenlijk niet te doen, omdat we verschillende commando's tot onze beschikking hebben waarmee we een
‫shell in de container zelf kunnen krijgen terwijl deze draait.
‫De eerste is alleen de opdracht docker container run.
‫Maar we gaan een paar extra opties specificeren.
‫We gaan een -het doen.
‫De -het zijn eigenlijk twee afzonderlijke opties.
‫Als ik de hulp heel snel laat zien, kun je zien dat de t ons een pseudo-tty of een prompt geeft die
‫lijkt op wat je zou hebben via ssh.
‫En als we dan omhoog scrollen naar i, is
‫dat echt wat ons in staat stelt om die sessie open te houden, zodat we meer commando's kunnen blijven uitvoeren.
‫Als we een docker-container uitvoeren, voer dan -it uit en voer vervolgens een andere nginx uit. Laten we het een proxy noemen.
‫Dan moeten we een alternatief commando specificeren.
‫Als je je aan het begin van deze sectie herinnert waar we het hadden over het
‫formaat van de docker-opdrachtregel, wanneer je een docker-containerrun uitvoert, zoals je kunt zien in de help, hier aan het einde, na de
‫afbeelding, heb je optionele opdracht en argumenten die u kunt verzenden naar deze nieuwe container die u gaat
‫beginnen om hem te vertellen wat hij moet uitvoeren. De afbeelding heeft een standaardopdracht die we later zullen zien
‫hoe te configureren.
‫Maar als u wilt wijzigen wat er bij het opstarten werd uitgevoerd, kunt u dat rechtstreeks vanaf de run-regel doen.
‫Laten we zeggen Bas. Omdat Bash een van de meest voorkomende shells is die je normaal gesproken zou vinden in een
‫container die je een shell geeft om mee te werken.
‫Moet je zien. Ik zit in een prompt.
‫U zult merken dat mijn prompt zegt dat root de gebruiker is als wie de container is gestart. Het betekent niet echt dat ik root op
‫de host ben.
‫Het betekent alleen dat ik als root op de container acteer.
‫Dat nummer erna is eigenlijk de container-ID.
‫Als ik een ls -al doe, krijg ik een volledige lijst van alles waar ik ben.
‫En je kunt zien dat ik in het rootpad van het bestandssysteem in de container zit.
‫Ik kijk eigenlijk naar alle bestanden in de container die is gebaseerd op de Nginx-afbeelding.
‫Vanaf hier zou ik configuratiebestanden kunnen wijzigen, pakketten van internet
‫kunnen downloaden en zo ongeveer alle gebruikelijke administratieve handelingen kunnen doen die je zou
‫doen vanuit een normale shell.
‫Om uit de shell te komen als je klaar bent, typ ik exit, zoals je zou doen met elke shell en nu
‫die container is gestopt.
‫Als we daadwerkelijk een docker-container ls zouden doen, zou je die daar niet zien.
‫Vergeet niet dat we het proxy noemden.
‫Dus ik moest een -a doen.
‫En het is er. Zie nu de opdracht die het heeft uitgevoerd. De standaardopdracht voor een Nginx-container is om het Nginx-programma
‫zelf uit te voeren.
‫Maar toen we onze laatste opdracht typten, veranderden we dat standaardprogramma in Bash,
‫wat ons onze shell gaf. Toen we de schelp verlieten, stopte de container. omdat container s worden alleen uitgevoerd zolang het
‫commando dat het bij het opstarten heeft uitgevoerd, wordt uitgevoerd. Sinds we het in Bash hebben veranderd, gewoon Bash afsluiten, stop het. Wat
‫als ik
‫een volledige distributie van Linux zou gebruiken in plaats van de Nginx daadwerkelijk te doen. Laten we een volledige
‫Ubuntu doen.
‫Het gaat eigenlijk de Ubuntu-afbeelding downloaden en me in de prompt van deze nieuwe container plaatsen.
‫Als u ooit Ubuntu hebt gebruikt, kent u de apt-pakketbeheerder.
‫Dus die kan ik hier gebruiken. Net zoals ik zou doen in een standaard Ubuntu-server. Ik zou eigenlijk iets
‫apt-get install -y
‫curl kunnen
‫installeren.
‫Het ding over Ubuntu en andere distributies in een container is dat ze meestal erg minimaal zijn.
‫Op een live-cd of een download van de ISO van Ubuntu die je normaal op een virtuele machine
‫zou zetten, wordt standaard veel meer software geïnstalleerd dan op een Ubuntu-container, wat eigenlijk een zeer minimale
‫versie van Ubuntu is die je altijd kunt toevoegen software met de apt-pakketbeheerder.
‫Dus nu is curl in deze draaiende container geïnstalleerd en kan ik het gebruiken zoals ik dat op een lokale computer zou doen.
‫Zodra ik de shell weer verlaat, stopt het de container daadwerkelijk. docker-container ls.
‫Je merkt dat ik het niet zie. Er is die Ubuntu-afbeelding die we net hebben uitgevoerd.
‫Als ik die container opnieuw zou opstarten, zou er curl in zijn geïnstalleerd.
‫Maar als ik een nieuwe container van de Ubuntu-afbeelding zou maken, zou in die andere container de curl-opdrachtregel
‫niet zijn geïnstalleerd.
‫Wat als we die container opnieuw wilden uitvoeren en Bash er meteen weer in wilden krijgen.
‫We zouden de opdracht docker container start kunnen gebruiken.
‫U zult merken dat het iets anders is wanneer we een bestaande container starten, maar het is vergelijkbaar
‫met de it... het is gewoon een ai.
‫Dan de naam van onze container Ubuntu. Je zult merken dat we er meteen weer in zitten
‫en ik kan google weer opkrullen en het werkt.
‫Als ik afsluit, stopte het weer.
‫Wat als ik de shell in een actieve container wil zien die al iets als
‫MySQL of Nginx draait.
‫Wij kunnen dat ook.
‫En dat is met behulp van het exec-commando. docker container exec.
‫En je kunt zien dat we hier een paar opties hebben.
‫En de meest voorkomende is... laten we zeggen dat ik in de MySQL-container wil springen omdat ik
‫wat administratieve dingen op de MySQL zelf moet doen.
‫Ik zou het opnieuw kunnen doen en dan de naam van de container. Dan het programma dat ik wil draaien.
‫En in dit geval is het weer Bash en ik zit nu in de container met MySQL.
‫Ik kan eigenlijk een ps aux doen in de container die de processen opsomt. Dit zal me natuurlijk de MySQL-daemon laten
‫zien die op de achtergrond draait, evenals het Bash-proces waarin ik momenteel zit,
‫evenals het ps-commando dat ik
‫zojuist heb uitgevoerd. In deze shell kon ik in MySQL zelf springen met de mysql-opdrachtregel. Je zult merken dat wanneer
‫ik deze Bash-shell verlaat en een ls doe, MySQL nog steeds actief is. Omdat de docker container exec feitelijk een extra proces uitvoert
‫op een bestaande actieve container, heeft dit geen invloed
‫op het rootproces voor de MySQL-daemon. Laten we er nog een proberen.
‫Zoals je hier kunt zien, is dit erg handig om in containers te springen wanneer je
‫problemen moet oplossen of wanneer je iets moet veranderen aan een draaiend systeem, en om containers met verschillende distributies te gebruiken om
‫je de omgeving te geven die je zou hebben als je had een volledige machine zoals een Ubuntu
‫of een Alpine.
‫Wat is Alpine nu? We hebben Alpine nog niet eerder genoemd. Alpine is een andere distributie van Linux, maar Alpine
‫is ontworpen om erg klein te zijn.
‫Het is eigenlijk maar 5 MB groot.
‫Als ik een docker-pull alpine doe, zal dat de nieuwste Alpine-afbeelding naar beneden halen en als ik een docker-afbeelding ls
‫doe, kun je zien hoe klein de Alpine-afbeelding is in vergelijking met de Ubuntu.
‫Het leuke van Alpine is dat het ook wordt geleverd met een eigen pakketbeheerder.
‫Je zult Alpine dus veel zien als een optie op Docker Hub in de volgende sectie wanneer we afbeeldingen en Docker
‫Hub bespreken.
‫Maar laten we voor nu een Bash-shell in Alpine doen. docker container run -it alpine bash.
‫Wat is hier nou net gebeurd?
‫Waarom ben ik daar binnen gestapt?
‫Het vertelt me dat het het containerproces start en het veroorzaakte dat het uitvoerbare bestand bash
‫niet in het pad werd gevonden. En wat dat echt betekent, is dat Bash niet in de container zit.
‫En dit gaat terug op het concept dat we alleen dingen in de container kunnen uitvoeren die al in zijn
‫afbeelding
‫bestond toen je hem startte.
‫Of misschien iets dat je later hebt toegevoegd via de exec of run-commando's.
‫Maar hoe kom ik in dit geval in het Alpine-beeld?
‫Welnu, Alpine is zo klein dat er eigenlijk geen Bash in zit. Maar het heeft wel sh. We kunnen het commando dus vervangen
‫door sh, wat niet zo volledig is als Bash, maar ons wel meteen in de container brengt.
‫Als je Alpine Linux op internet zou doorzoeken, zou je ontdekken dat de pakketbeheerder apk is
‫en dat we die zouden kunnen gebruiken om Bash te installeren als we het echt nodig hadden.
‫Om even kort samen te vatten wat we in deze les hebben geleerd.
‫We leerden over de -it-optie voor containerrun, die ons het equivalent van een interactieve shell geeft om dingen in de container
‫te doen zoals we zouden doen als we naar een of andere server zouden worden gesshd.
‫Toen leerden we een
‫nieuw commando voor docker container exec met it dat precies hetzelfde doet als run, maar het doet het
‫op een bestaande container die draait en start geen nieuwe container.
‫En als laatste leerden we wat over Alpine en hoe dat verschilt van grote Linux-distributies
‫en hoe het eigenlijk 4 MB groot is en ideaal voor container-images.