Un monde d'octets

Depuis 4 jours j'ai accidentelement fait mes commits sur la mauvais branche.

Par chance, personne n'a commité en même temps que moi, j'ai donc pu procéder au nettoyage comme suit :

git reset --hard <sha>
git clean -f -d
git push -f

Et voila, la branch est revenue à l'état du <sha> spécifiée, tout propre !

Branch naming

Create a branch by following the naming convention: <type>/<taskid>-<description-of-branch>.

<type> is:

• feat - for new code (features, functionalities, etc.)
• fix - for code updates (issue fixing, improvements)
• delete - for deletion, removal, undoing of code
• docs - for documentation
• test - for code testing. NEVER merged these branches to master.

<taskid> is the ID of the work-item created previously.

<description-of-branch> describes what is accomplished on the branch. Use maximum 3 words, all lowercase, words separated by hyphens.

Examples

• docs/1-remove-repository
• feat/5-add-motd-task
• fix/42-rename-workload-subscription

Conventional commit messages

Use conventional commit message when commiting changes to a branch: <type>: <description>

<type> is:

• feat - for new code developments
• fix - for fixes and improvements
• delete - for permanent deletion of code
• docs - documentation only changes
• style - update formatting (white-spaces, indentation, etc.)

Examples

• feat: add task to define motd on the node
• fix: change published port used by container from 22 to 4444
• docs: update section getting-started with contribute details in project readme
• style: delete all trailing spaces in terraform files

Pull request

Choose two branches to see what’s changed or to start a new pull request

• source: <name-of-your-branch>
• into: master (always)

Use a descriptive title to explain what the PR addresses.

Examples

• add doc about azure naming conventions to wiki
• deploy storage account for tfstate on production subscription
• refactor code for ansible role bootstrapping a linux virtual machine

The PR description contains a human-readable description of what changes are addressed with the PR. It aims at assisting the reviewers that are reading the PR. Each lines are less than 100 characters. All lower case. Indicate the related task (with prefix fixed or related), and the related user-story (with prefix related).

Examples

• fixed: #1
• related: #3

add description of naming conventions used for every resource deployed on azure with infrastructure-as-code

Pour m'autoformer sur gitlab et la partie CI, j'ai remonté mon microk8s, installé gitlab en docker, connecté mon gitlab a kubernetes et ajouté un runner en contexte kubernetes.

Il ne restait plus qu'a prendre un projet docker, et a essayer de le builder avec upload dans ma registry privée.

Les tests avec les images docker et docker-dind m'ont posé plus de problèmes qu'autre chose. Je me suis finalement rabbatu sur buildah.

Dans les problèmes rencontrés, il y'a eu le tagging, ou faute d'expérience, il a fallu que je comprenne quoi mettre dans les valeurs pour que ma registry ne rejette pas pour défaut de manifest.

Il a aussi fallu ajouter l'option de tls a la commande buildah pour qu'il n'échoue pas en se plaignant que ma registry ne supporte par https.

voici le .gitlab-ci.yml pour la partie build :

stages:
  - build

build and push to gitlab registry:

  stage: build
  image: fcadeillan/buildah

  variables:
    BUILDAH_FORMAT: "docker"
    IMAGE_NAME: "db2http"
    IMAGE_FQN: "192.168.1.30:5000/db2http"

  before_script:

  script:
    - buildah bud -t ${IMAGE_FQN}:${CI_COMMIT_REF_SLUG} .
    - buildah push --tls-verify=false docker://${IMAGE_FQN}:${CI_COMMIT_REF_SLUG}

Enfin voila une bonne chose de faite. Prochaine fois, on attaquera le déploiement sur kubernetes pour faire bonne figure !

La sauvegarde de gitlab via la commande

gitlab gitlab-rake gitlab:backup:create SKIP=registry,artifacts,lfs,builds

crée une archive tar qiu contient des bundle de projets git.

Ces gundles sont eux aussi une forme d'archive de fichier et données de git, on peut les utiliser comme une copie de repo local, en précisant le bundle à la place de l'url du répo.

On peut par exemple lister le contenu des entêtes avec :

git bundle list-heads blob.bundle

Pour notre premier pipeline, nous allons simplement créer un fichier et tester son existence.

Pour créer un pipeline dans Gitlab, il faut publier un fichier .gitlab-ci.yml contenant :

• des stages
• des jobs relatifs aux stages
• des artefacts permettant de lier les jobs entre eux

stages:
  - build
  - test

build: 
  stage: build
  script: 
    - echo "Building"
    - mkdir build
    - touch build/info.txt
  artifacts: 
    paths:
      - build/

test: 
  stage: test
  script:
    - echo "Testting"
    - test -f "build/info.txt"

Ici nous avons un stage de build, et un stage de test. les scripts sont simple, et nous ne les détaillerons donc pas.

La partie importante ici est l'Artifact. Dans notre premier job, nous créons un fichier, et dans notre deuxième job, testons son existence. mais chaque jobs est initialement indépendant.

Comme l'indique la doc sur le site de Gitlab :

Job artifacts are a list of files and directories created by a job once it finishes. This feature is enabled by default in all GitLab installations.

En gros, notre définition d'Artifact définit que les fichiers créés dans le premier job dans le répertoire build sont à conserver pour les jobs suivants. En pratique, gitlab conservera dans son repository le contenu du dossier build et il sera ainsi récupérable par les autres jobs. Et la continuité est faite.

Mise en place du serveur

Parcourons les étapes de la mise en place d'un accès SSH côté serveur. Dans cet exemple, vous utiliserez la méthode des authorized_keys pour authentifier vos utilisateurs. Nous supposerons également que vous utilisez une distribution Linux standard telle qu'Ubuntu. Premièrement, créez un utilisateur 'git' et un répertoire .ssh pour cet utilisateur.

sudo adduser git --disabled-password --gecos "Git System Account" --disabled-login
su git
cd
mkdir .ssh

Ensuite, vous devez ajouter la clé publique d'un développeur au fichier authorized_keys de l'utilisateur Git. Supposons que vous avez reçu quelques clés par e-mail et les avez sauvées dans des fichiers temporaires. Pour rappel, une clé publique ressemble à ceci :

cat id_rsa.john.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair

Il suffit de les ajouter au fichier authorized_keys :

cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys

Maintenant, vous pouvez créer un dépôt vide nu en lançant la commande git init avec l'option --bare, ce qui initialise un dépôt sans répertoire de travail :

cd /opt/git
mkdir projet.git
cd projet.git
git --bare init

Alors, John, Josie ou Jessica peuvent pousser la première version de leur projet vers ce dépôt en l'ajoutant en tant que dépôt distant et en lui poussant une branche. Notons que quelqu'un doit se connecter au serveur et créer un dépôt nu pour chaque ajout de projet. Supposons que le nom du serveur soit gitserveur. Si vous l'hébergez en interne et avez réglé le DNS pour faire pointer gitserver sur ce serveur, alors vous pouvez utiliser les commandes suivantes telles quelles :

1. Sur l'ordinateur de John

cd monproject
git init
git add .
git commit -m 'premiere validation'
git remote add origin ssh://git@gitserveur:/opt/git/projet.git
git push origin master

À présent, les autres utilisateurs peuvent cloner le dépôt :

git clone ssh://git@gitserveur:/opt/git/projet.git

Puis faire des modifications

cd projet
vim LISEZMOI
git commit -am 'correction fichier LISEZMOI'
git push origin master

De cette manière, vous pouvez rapidement mettre en place un serveur Git en lecture/écriture pour une poignée de développeurs.

En précaution supplémentaire, vous pouvez simplement restreindre l'utilisateur 'git' à des actions Git avec un shell limité appelé git-shell qui est fourni avec Git. Si vous positionnez ce shell comme shell de login de l'utilisateur 'git', l'utilisateur 'git' ne peut pas avoir de shell normal sur ce serveur. Pour utiliser cette fonction, spécifiez git-shell en lieu et place de bash ou csh pour shell de l'utilisateur. Cela se réalise généralement en éditant le fichier /etc/passwd :

sudo vim /etc/passwd

Tout au bas, vous devriez trouver une ligne qui ressemble à ceci :

git:x:1000:1000::/home/git:/bin/sh

Modifiez /bin/sh en /usr/bin/git-shell (ou le résultat de la commande which git-shell qui indique où il est installé). La ligne devrait maintenant ressembler à ceci :

git:x:1000:1000::/home/git:/usr/bin/git-shell

À présent, l'utilisateur 'git' ne peut plus utiliser la connexion SSH que pour pousser et tirer sur des dépôts Git, il ne peut plus ouvrir un shell. Si vous essayez, vous verrez un rejet de login :

ssh git@gitserveur

fatal: What do you think I am? A shell?
Connection to gitserveur closed.