Introducción al Desarrollo de software usando containers en local mediante Earthly. Para evitar issues en entorno de continuous integration y continuous delivery que no puedan replicarse facilmente

1. Earthly
Dockerfile con esteroides
by @mario21ic

2. Me presento
● Mario Inga C.
● Miembro de comunidades: DevOps Perú,
Docker Lima y Cloud Native Perú.
● Software Development, Cloud, SysAdmin,
Security.
● Trabajo en Voltron Data
● Metal m/
● Twitter: @mario21ic

3. Docker: Build once, Run Anywhere
Code + Dockerfile = Docker Image
Docker Hub
Quay.io
Cloud Repositories
Other solutions
On premise

4. Local + CI + CD
● CI: “fail Fast & fail First” -> app & tests
● Si no falla, hace deploy a un environment como Dev, QA,
Stage, etc para pruebas manuales.
● Y Local?
Local CI CD

5. Local
● Code
● Tasks:
○ Lint
○ Unit tests
○ Integration tests
○ Build
● Tools:
○ Bash Scripts
○ Makefile
○ Dockerfile multistage (lint, tests, build)
● Probar manualmente el app

6. CI Server
● Configuracion (url, users,
permissions, etc)
● Credenciales (tokens, ssh
keys, etc)
● Plugins (docker, k8s, sonar,
etc)
● Pipeline steps:
○ Scripts
○ Jenkinsfile
○ Yaml
● Se genera una fuerte
dependencia del CI Server.

7. Y cuando aparece un issue SOLO en CI?
● Contexto:
○ Teniamos los build steps en el CI server (no repositorio).
○ Definimos todos los build steps en el formato del CI tool
(Jenkinsfile, yaml files).
○ Abusar del uso de Jenkins plugins, generando una fuerte
dependencia con Jenkins.
● Cómo replicar el issue en Local?
○ Levantan un Jenkins en local? Y los plugins, configs,
credentials, etc?
○ Interpretar el yaml file y crean un script? Eso es redundar
no?
● Descargar Docker images y poner el code?
● Prueba y Error? Enviar commits tras commits.

8. ●
Antes de Docker

9. ●
Ahora con Docker

10. Algunas reflexiones
● Docker: Build once, Run anywhere.
● Enpaquetamos en App en Docker pero y los
steps de CI/CD?
● Desarrollamos en Local: build, run unit &
integration tests, etc sin Containers.
● Esperamos que recién falle en CI (donde se
ejecutan en Containers)

11. Y si usamos los Containers en Local?
● Containers para:
○ Lint
○ Unit Tests
○ Integration Tests
○ Build
● Mantenimiento de: Dockerfiles,
Makefiles, Bash Scripts, etc.
● Primero los Steps del CI usando
Containers en Local.
● Al final Empaquetamos el App en un
Docker Image.

12. usando Containers en Local:
● Building:
○ Dockerfile: gcc, g++, go, rustc, jdk, etc
● Runtime:
○ Dockerfile: java runtime (jre), scratch, ubuntu, centos, etc
● Orquestacion:
○ docker-compose.integration-tests.yml
○ docker-compose.tasks.yml
● Bash scripts usan binarios que no son iguales en
todos los SOs, ejem grep, find, etc.
● Scripts para: docker build de image, docker run para
tareas (deps, run unit & integration tests, build, etc).
● Makefile para orquestar los scripts, ejem: clean &&
build && tests.

13. Problemas: Orientado a ejecutar en CI.

14. Propuesta: Orientado a ejecutarse en cualquier lugar.

15. Why Earthly?
● 🐳 Build anything via containers
● 🛠 Programming language agnostic
● 🔁 Repeatable builds
● ⛓ Parallelism that just works
● 🏘 Mono and Poly-repo friendly
● 💾 Shared caching
● 🔀 Multi-platform
● Open source https://github.com/earthly/earthly
● Web https://earthly.dev/

16. ❤ Makefile + Dockerfile = Earthfile
● What if Dockerfiles and
Makefiles had a Baby
● Repeatable builds
● A familiar syntax
● Cache for more speed.
● Targets:
$ earthly ls

17. Demo time sin Earthly
● Golang app calculator
● Docker + Makefile + Scripts
● Tasks:
a. Lint
b. Unit Tests
c. Build
d. Docker (image)
● Jenkins:
a. Sin Docker requiere: go, gcc,
makefile, etc
b. Con Docker usando Multistage (no
son jenkins build stages) o sino Bash
Scripts.

18. 1) CI Pipeline con Plugins
● Ventajas:
○ Diferentes stages: Deps, Lint, Unit Tests, Build, Docker Image
○ Solo defines un agent con docker image “golang:1.17-alpine”
● Desventajas:
○ Requiere Docker Plugin y Docker Pipeline Plugin
○ Todos los steps estan en el Jenkinsfile_plugins. Dificil mantener y replicar.

19. 2) CI Pipeline con Dockerfile Multistage
● Ventajas:
○ Todo en Uno.
● Desventajas:
○ Un solo stage: Deps, Lint, Unit Tests, Build todo dentro del Dockerfile.
○ Reiniciar desde un punto
○ Jenkinsfile no usa “make docker”, llama directo al script ./docker-build.sh.

20. 3) CI Pipeline con Containers
● Ventajas:
○ Buena visibilidad.
● Desventajas:
○ Jenkinsfile_containers tuvo que crear el docker Image Build (base).
○ Muchos scripts: los que Automatizan en local y los que ejecutan estos en Containers.
○ El script ./build-con-docker.sh solo para Local, porque el entregable es Docker Image.

21. Demo time con Earthly
● Golang app calculator
● Earthly
● Tasks:
○ Lint
○ Unit Tests
○ Build
○ Docker (image)
● Jenkins:
○ Requiere Earthly

22. Demo: Deps & Lint
● Deps:
$ earthly +deps
● Lint:
$ earthly +lint
# Corregir y probar (cache)
$ earthly +lint
$ earthly --no-cache +lint

23. Demo: Build & Docker
● Build:
$ earthly +build
$ file build/go-example
● Docker:
$ earthly +docker
$ docker run go-example
● All in one:
$ earthly +all

24. CI Pipeline con Earthly
● Cada Stage refleja el trabajo en Local.
● Visibilidad
● Altamente Replicables.
● Puede mejorar con Stages en paralelo.

25. Extra: Build for Multi Architecture.
● Build:
$ earthly --platform=linux/amd64 +build
$ file build/go-example
$ docker run --platform=linux/amd64 -v $PWD/build:/tmp ubuntu:20.04 /tmp/go-example
● Docker:
$ earthly --platform=linux/amd64 +docker
$ docker run go-example:latest_linux_amd64
Mas info https://docs.earthly.dev/docs/guides/multi-platform
https://docs.docker.com/desktop/multi-arch/

26. 1. DRY => Don’t Repeat Yourself
2. KISS => Keep It Simple Stupid
3. RTFM => Read the fu**ing manual.
4. Earthly Docs https://docs.earthly.dev/basics
5. Poner nombres autodescriptivos para todo.
6. Enamorarse del problema y NO de la solución.
7. Evitar Obsession tool (mucho acoplamiento)
8. No existen las balas de plata.
Algunas recomendaciones

27. Preguntas?
Pueden encontrarme
en Twitter
@mario21ic