De container draait niet

Je hebt het containergedeelte van het script geplakt en er gebeurt niets. /container print geeft een lege lijst, of de container staat er wel maar met status stopped of error, of hij lijkt te draaien en is nergens bereikbaar.

Wat het niet is: dit is zelden een fout in het image of in de netwerkinstellingen. Containers op RouterOS hebben voorwaarden die allemaal moeten kloppen voordat er ook maar iets gebeurt, en twee daarvan zijn bewust lastig gemaakt: een fysieke bevestiging aan het apparaat zelf, en het gegeven dat een container nadrukkelijk gestart moet worden nadat hij is aangemaakt. Begin dus niet met graven in mounts en omgevingsvariabelen, maar loop de voorwaarden langs.

De snelle controles, op volgorde

1. Mag dit apparaat containers draaien? /system resource print en kijk naar architecture-name. Goed antwoord: arm64, x86_64 of tile. Staat er mipsbe, smips of arm, dan houdt het hier op: er is geen containerpakket voor.
2. Zit het pakket erop? /system package print. Goed antwoord: een regel container, ingeschakeld. Anders eerst downloaden bij MikroTik, uploaden en herstarten.
3. Staat device-mode goed? /system device-mode print. Goed antwoord: container: yes. Staat er no, dan is de bevestiging nooit gedaan en doet het hele menu /container niets.
4. Bestaat de schijf? /disk print. Goed antwoord: een regel waarvan de naam precies overeenkomt met wat er in root-dir staat. Vaak heet hij niet disk1 maar usb1-part1, en dan klopt elk pad in het script niet.
5. Wat zegt de container zelf? /container print detail. Goed antwoord: status: running. Extracting betekent dat hij nog bezig is met uitpakken, stopped betekent dat hij nooit gestart is, error betekent dat het logboek je meer vertelt.
6. Wat zegt het logboek? /log print where topics~"container". Dit is de belangrijkste regel van dit hoofdstuk. Hier staat waarom het pullen mislukte, welk pad niet bestond of welke variabele ontbrak.
7. Is er ruimte? /disk print. Goed antwoord: ruim meer vrij dan het image groot is. Zie Geen ruimte.

De gewone oorzaken, meest voorkomend eerst

Device-mode is nooit bevestigd

De regel /system device-mode update container=yes zet niets om. Hij vraagt iets, en je hebt daarna vijf minuten om het bij het apparaat te bevestigen: de resetknop indrukken, of de stroom eraf en er weer op. Doe je dat niet binnen die tijd, dan vervalt het verzoek stilletjes en werkt geen enkele containerregel. Dat is met opzet: containers kunnen alles, dus MikroTik wil dat er iemand bij staat.

De schijfnaam klopt niet

Elk pad hangt aan de naam van de schijf: de root-dir, de map met lagen, de tijdelijke map voor het pullen en de bronnen van de mounts. Heet je stick anders dan wat er is ingevuld, dan mislukt alles tegelijk en met verwarrende meldingen. Kijk in /disk print en gebruik die naam letterlijk.

De container is aangemaakt maar nooit gestart

Een container aanmaken en een container starten zijn twee losse handelingen. Na het aanmaken is de status stopped. Start hem met /container start [find comment="pihole"] en kijk daarna opnieuw naar de status.

Het image kon niet worden opgehaald

Pullen gebeurt vanaf de registry over internet. Daar is DNS voor nodig, een werkende uitgaande verbinding en ruimte voor de lagen. Werkt DNS op de router zelf niet, dan komt er niets binnen. Test met :put [:resolve registry-1.docker.io].

Het image past niet bij de architectuur

Een image dat alleen voor amd64 bestaat, draait niet op een arm64-router. Kijk bij het image welke platforms er zijn.

De container start en stopt meteen

Dat is bijna altijd het programma in de container, niet RouterOS. Een ontbrekende omgevingsvariabele, een map die niet gemount is of een configuratiebestand dat er niet staat. Het logboek van de container vertelt het; zet logging=yes aan als dat nog niet zo is.

Wat de configurator hiervan doet

• Het onderdeel Containers verschijnt alleen op apparaten waarvan de catalogus weet dat ze ARM64, x86 of Tile zijn. Op de rest zegt de tool dat containers ARM64 of x86 vereisen en houdt het daarbij op.
• De inleiding van het onderdeel zegt het meteen: /system/device-mode/update container=yes moet binnen vijf minuten fysiek bevestigd worden, en die regel staat daarom als eerste in dit deel van het script. Erboven staat als commentaar dat je na de bevestiging de rest van dit onderdeel opnieuw moet draaien. Een script in één keer plakken werkt hier dus niet; er zit met opzet een handeling in het midden.
• Het script maakt een bridge containers met het containernetwerk erop, een masquerade zodat containers naar buiten kunnen, en zet de registry-URL, de map voor lagen en de tijdelijke map op de schijf die je koos.
• Per container komt er een veth met adres en gateway, een bridge-poort, de omgevingsvariabelen, de mounts en de container zelf met start-on-boot=yes en logging=yes, plus een dstnat vanaf het LAN als je poorten invult.
• Wees hierover eerlijk: het script start de containers niet. Het eindigt met een commentaarregel die je het startcommando geeft en zegt waar de logs staan. Dat is bewust, want pullen kost tijd en ruimte en je wilt daarbij kunnen kijken. Door start-on-boot=yes starten ze wel na de eerstvolgende herstart.
• Het veld Opslag staat standaard op disk1, met de hulptekst dat je in /disk print moet kijken. De tool kan dat niet voor je controleren.
• In Systeem zit de geavanceerde schakelaar om onderdelen die device-mode blokkeert in een los script te zetten dat één keer bij de eerstvolgende start draait. Die eindigt met een activatietermijn van een dag: zet je het apparaat niet binnen een dag uit en aan, dan gaat het niet in.

Als het niet aan je router ligt

• De registry. Docker Hub beperkt het aantal pulls per adres. Bij een foutmelding over rate limiting: wachten of een andere registry.
• De USB-stick. Niet elke stick werkt op elk model, en een stick met het verkeerde bestandssysteem wordt niet gemount. Formatteer hem vanaf de router.

Verder lezen: Containers, Recept: AdGuard Home en Pakketten.