Container Images Bouwen Zonder Docker

Containers hebben zich bewezen als een robuuste technologie om applicaties consistent te builden en deployen. Het automatisch builden van deze containers is een essentieel onderdeel van de software delivery livecycle. Voor het builden van containers maken we gebruik van een daemon, maar dit is niet zonder risico's. Daarom duiken we in dit artikel in de wereld van Kaniko - een tool ontworpen om container images te bouwen zonder een daemon. En onderzoeken we hoe het kan worden geïntegreerd in een CI/CD pipeline.

Wat is Kaniko?

Kaniko is een open-source project van Google dat het builden van container images mogelijk maakt zonder dat er een daemon nodig is. Dit maakt het bijzonder nuttig in omgevingen waar de daemon niet kan of mag draaien, zoals in sommige CI/CD pipelines. Kaniko kan worden uitgevoerd in een Kubernetes-cluster of een ander platform dat containers orchestreert en kan images pushen naar elke gewenste container image registry.

Waarom Kaniko?

Er zijn verschillende redenen waarom je Kaniko zou willen gebruiken in je CI/CD pipeline:

• Veiligheid: Kaniko vereist geen verhoogde privileges, wat de veiligheid verhoogt, vooral in multi-tenant omgevingen.
• Vereenvoudiging: Kaniko elimineert de noodzaak om met daemon processen om te gaan, wat het proces vereenvoudigt en mogelijke problemen met daemon-interacties vermindert.
• Compatibiliteit: Het werkt op elke omgeving waar containers draaien, ongeacht de container runtime, waardoor een soepele overgang mogelijk is voor teams die al met Containers werken.
  

Aan de Slag met Kaniko

In het volgende voorbeeld gebruiken we Gitlab om met Kaniko een image te builden:

build and push:
stage: build
image:
name: gcr.io/kaniko-project/executor:v1.14.0-debug
entrypoint: [""]
before_script:
- echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s"\
"${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}"\
| base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
script:
- /kaniko/executor
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}"

Wat gebeurt hier:

• image: We gebruiken de kaniko debug image(gcr.io/kaniko-project/executor:debug), omdat deze een shell heeft. En we hebben de shell nodig om een image te kunnen bouwen met GitLab CI/CD.
• entrypoint: We overschrijven het entrypoint van de container met een leeg commando, zonder dit zouden before_script en script niet kunnen draaien.
• before_script: Onze registry heeft een user en authenticatie nodig, we gebruiken het before_script om Kaniko te configureren, zodat deze de juiste credentials heeft om in te loggen op de registry.
• script: Dit is waar de Kaniko magie plaatsvind. De kaniko werkt eenvoudig. Om te kunnen werken geef je aan wat de build context is, wat de dockerfile is en waar de image naartoe gepushed moet worden.
  

Deze job maakt zoveel mogelijk gebruik van Gitlab's pre-defined variabelen. CI_REGISTRY, CI_REGISTRY_USER en CI_REGISTRY_PASSWORDzal je zelf moeten instellen als variabel.

Conclusie

Kaniko biedt een efficiënte en veilige manier om container images te bouwen binnen CI/CD pipelines zonder afhankelijk te zijn van een daemon. Het minimaliseert de complexiteit en de veiligheidsrisico's die kunnen ontstaan bij het werken met Docker, terwijl het tegelijkertijd naadloos integreert met bestaande Dockerfiles en registries. Zo maakt Kaniko het gemakkelijker voor ontwikkelaars en DevOps-teams om applicaties snel, consistent en veilig te bouwen en te leveren.