---
title: Gatsby c'est magnifique !
date: "2020-01-13T01:01:01.101Z"
template: "post"
draft: false
slug: "gatsby-c-est-magnifique"
category: "Javascript"
tags:
  - "GatsbyJS"
  - "React"
  - "Gitlab"
  - "Gitlab-CI"
description: "Qu'est ce que c'est ? Pourquoi ce site existe ? Je raconte tout ... humblement et techniquement."
socialImage: "/media/gatsby.png"
---

<figure>
	<blockquote>
		<p>Ça fait un moment que je voulais tester GatsbyJs. Aujourd'hui, je me lance...</p>
		<footer>
			<cite>—voilà comment est né ce site.</cite>
		</footer>
	</blockquote>
</figure>

![Gatsby](/media/gatsby.png)

## Et alors ? 
Ça donne quoi [GatsbyJS](https://www.gatsbyjs.org/) ?

La dernière fois que j'ai eu à bosser avec un CMS c'était avec 
[Wordpress](https://fr.wordpress.com/). `GatsbyJS` est complètement différent.

Très certainement moins grand public mais tellement plus moderne ! 
L'architecture, les performances, les outils de dev ... 
pour en savoir +, une seule question à se poser : [WTF is JAMStack?](https://jamstack.wtf/)

Le test local d'un site à partir d'un des nombreux templates proposés
[ici](https://www.gatsbyjs.org/starters/?v=2) ou [là](https://codebushi.com/gatsby-starters-and-themes/)
est un jeu d'enfant (vraiment, y a une ligne à taper!)

Je me suis fixé quand même quelques challenges techniques...

## Intégration continue avec Gitlab

Mon but :

* automatiser le build d'une image `Docker` 
* automatiser la mise à jour de cette image dans `Kubernetes`

Tout ça à partir de Gitlab.

Voici le premier job de build du fichier 
[.gitlab-ci.yml](https://gitlab.com/kalmac/abdi.pro-static/blob/1-test-de-gatsby/.gitlab-ci.yml):

```yaml
build:
  image: kalmac/gatsby  # Une image Docker contenant les outils de dev
  stage: build
  script:
    - yarn              # Installation des dépendances avec yarn
    - gatsby build      # Build du site pour la production
  only:
    - master            # Au commit sur master
  tags:
    - docker            # Demander un runner de type Docker
```

Le résultat du build qui nous intéresse est généré dans le répertoire `public`.
La mise en cache le rend disponible pour les jobs suivants :

```yaml
cache:
  paths:
    - public          # Mise en cache du répertoire /public
    - node_modules    # et du node_modules
```

On enchaine ensuite avec le job de création de l'image Docker :

```yaml
release:
  image: docker:latest  # Image docker
  services:
    - docker:dind       # Service Docker-in-Docker
  stage: release
  script:               # On construit l'image docker
    - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build --no-cache --pull -t $CONTAINER_RELEASE_IMAGE .
    - docker push $CONTAINER_RELEASE_IMAGE
  only:
    - master            # Au commit sur master
  tags:
    - docker            # Demander un runner de type Docker
```

Ici on `build` et on `push` l'image Docker dans le registry de Gitlab
grâce aux variables suivantes :

```yaml
variables:
  CONTAINER_RELEASE_IMAGE: registry.gitlab.com/$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME
  DOCKER_HOST: tcp://docker:2375
```

## La dockerisation totale

Comme je teste beaucoup de langages et technos différentes, j'ai pris l'habitude d'utiliser 
[Docker](https://hub.docker.com/) pour ne rien installer sur mes postes.

*Vous récupérez le projet Git,*
*vous lancer `dockerenv` et vous avez accès aux commandes*
*`gatsby` et `yarn` dont vous avez besoin.*

Mais ça c'est une autre histoire ...