Planet-Libre

genma : Lifehacking - L'application Gnome Pomodoro

vendredi 15 mai 2020 à 09:00

Lifehacker depuis plusieurs années, en témoigne mes nombreux et différents billets sur le sujet, je connaissais la technique Pomodora que j'applique par des phases de focus sur une tâche précise, sans jamais avoir franchie la phase de minuter avec exactitude le temps passé sur une tâche.

La technique Pomodorose présente sous la forme de cinq étapes :
décider de la tâche à effectuer ;
régler le pomodoro (minuteur) sur 25 minutes ;
travailler sur la tâche jusqu'à ce que le minuteur sonne et la noter comme faite ;
prendre une courte pause (5 minutes) ;
tous les quatre pomodori prendre une pause un peu plus longue (15-20 minutes).

Si on ne souhaite pas utiliser un minuteur physique (une tomate ou autre), une application sur son smartphone, il existe une application pour les distributions GNU/Linux, Gnomepomodoro https://gnomepomodoro.org/

Cette application GNOME permet de gérer le temps selon la technique Pomodoro. Il entend améliorer la productivité et la qualité du travail en vous rappelant de prendre de courtes pauses. Ce flux de travail peut améliorer la concentration, la santé physique et l'agilité mentale selon la façon dont vous passez vos pauses et la rigueur avec laquelle vous suivez la routine.

Très légère, très simple, configurable pour la durée des sessions de pomodoro et des intervalles entre et de pause, cette application pourra être lancée en début de journée pour être utilisée tout au long de celle-ci. A tester et adopter, si on fait des vrais pomodoro dans les règles de l'art.

Original post of genma.Votez pour ce billet sur Planet Libre.

genma : Yunohost - Nextcloud - Migration d'un nom de domaines à un autre

mardi 12 mai 2020 à 09:00

Pour une raison ou une autre, on peut vouloir déplacer une instance Nextcloud / la migrer d'un nom de domaine à un autre. Cela peut se faire sur une même machine ou d'un serveur à un autre (via un système de sauvegare restauration qui ne sera pas abordé ici).

Un cas concret est par exemple le fait de déplacer une installation de Nextcloud sur Yunohost d'un domaine à un sous-domaine (ou d'un sous-domaine à un autre). Après avoir créer le sous-domaine, dans la partie configuration de l'application, on peut choisir quel domaine se trouve l'application et si elle est l'application par défaut (elle est alors à la racine de ce sous-domaine).

Une fois que c'est fait, il reste une manipulation à faire. En effet, quand on va via son navigateur sur la nouvelle adresse du Nextcloud, on tombe sur le massage suivant :

"Accès à partir d'un domaine non approuvé
 Veuillez contacter votre administrateur. Si vous êtes un administrateur, éditez la variable "trusted_domains" dans le fichier config/config.php comme l'exemple dans le fichier config/config.sample.php.
 Vous trouverez d'autres informations sur la configuration dans la documentation ."

Il faut donc, via un compte ayant les droits (root ou via sudo) éditer le fichier

#nano /var/www/nextcloud/config/config.php


 Et changer les champs suivants : 

 'trusted_domains' => 
 array (
 0 => 'localhost',
 1 => 'nouveau-sous-domaine.com',
 ),
 (...) 
 'overwrite.cli.url' => 'https://nouveau-sous-domaine.com',

En remplaçant le nom de domaine.

Remarque : Attention à la syntaxe, les lignes se terminent par un ",".

Et si besoin, toujours dans le même fichier, la ligne qui correspond à l'adresse sur laquelle on se retrouve (cas d'une installation sur Yunohost pour l'exemple cité)

'logout_url' => 'https://domaine-yunohost-par-defaut/yunohost/sso/?action=logout',

Original post of genma.Votez pour ce billet sur Planet Libre.

Littlewing : Utiliser des GITHUB Actions pour déployer dans Google Kubernetes Engine

dimanche 10 mai 2020 à 09:22

A mes heures perdues, je travaille sur un « POC/side project qui n’aboutira pas et je m’en fiche » basé sur Quarkus. J’ ai choisi d’utiliser les langages et composants suivants :

Kotlin
Quarkus
Gradle
Kubernetes pour le déploiement

Oui, tant qu’à faire, autant aller dans la hype …

Mon projet est sur GITHUB. Pour automatiser certaines actions et, disons-le, par fierté personnelle, j’ai choisi d’automatiser certaines actions par la mise en œuvre de pipelines CI/CD.
Depuis peu, GITHUB a intégré un mécanisme de pipeline : GITHUB Actions.

Ça permet, entre autres, de lancer des processus automatisé sur un push ou sur une action pour un commit GIT.

La force de l’outil est, selon moi, de facilement s’intégrer avec beaucoup de services du cloud ( sonarcloud, google cloud, heroku,…). On aime ou on n’aime pas, mais chez Microsoft, l’intégration ils savent faire.

Par exemple, si on veut lancer une compilation lors d’un push, on peut placer un fichier .github/workflows/build.xml avec le contenu :

name: CI

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Build with Gradle without testing
        run: ./gradlew build -x test

Coté GITHUB, vous verrez l’exécution sur un écran dédié

Vous pouvez créer autant de workflows que vous souhaitez (si votre projet est en libre accès).
Pour chaque workflow, on peut définir et utiliser des jobs. Les logs d’exécution sont disponibles dans ce même écran:

Worflows implémentés

J’ai choisi d’implémenter les workflows suivants:

CI: Build sur la feature branch
CD: Build sur master branch et déploiement

On obtient donc dans mon cas:

Ce n’est pas parfait. Loin de là. Dans la « vraie vie », pour une équipe de dev, je l’améliorerai sans doute par un build docker dans les features branches, une validation formelle et bloquante de l’analyse sonar, etc.
Pour un dev perso ça suffit largement. Le contenu de la branche master est compilé et une image docker est crée pour être déployée automatiquement dans GKE.

Analyse SONAR

J’ai choisi d’utiliser sonarcloud pour analyser mon code. C’est gratuit pour les projets opensource. L’analyse se fait simplement:

  sonarCloudTrigger:
    name: SonarCloud Trigger
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: SonarCloud Scan
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
        run: ./gradlew jacocoTestReport sonarqube

Dans ce job j’utilise deux secrets. Ce sont des tokens qui permettent de ne pas stocker en dur les données dans les repos GITHUB.

Création d’une image Docker et déploiement dans le registry GITHUB

Ici aussi, ça se fait simplement. La preuve :

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Set up JDK 11
        uses: actions/setup-java@v1
        with:
          java-version: 11
      - name: Build in JVM Mode with Gradle without testing
        run: ./gradlew quarkusBuild  [1]
      - name: Branch name
        run: echo running on branch ${GITHUB_REF##*/}
      - name: Build the Docker image Quarkus JVM
        run: docker build -f src/main/docker/Dockerfile.jvm -t docker.pkg.github.com/${GITHUB_REPOSITORY}/music-quote-jvm:latest .  [2]
      - name: Login against github docker repository
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: docker login -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}  docker.pkg.github.com   [3]
      - name: Publish the Docker image Quarkus JVM
        run: docker push docker.pkg.github.com/${GITHUB_REPOSITORY}/music-quote-jvm:latest  [4]

Création du binaire
Création de l’image docker en utilisant la commande docker et le Dockerfile fourni par Quarkus
Identification sur la registry Docker de GITHUB
Déploiement de l’image

Pour plus de détails sur la variable GITHUB_TOKEN, vous pouvez lire cet article de la documentation.

Déploiement dans Google Kubernetes Engine

Mon application est pour l’instant architecturée comme suit (attention c’est compliqué):

Pour la déployer dans Google Kubernetes Engine, j’ai besoin d’ implémenter cette « architecture » par les objets Kubernetes suivants:

J’utilise les objets suivants:

Des services pour exposer la base de données ainsi que l’application
Un deployment pour l’application
Des pods car à un moment, il en faut…
Un statefulset pour la base de données

Vous pourrez trouver la définition de tous ces objets au format yaml via ce lien. J’ai fait très simple. Logiquement j’aurai du créer un volume pour les bases de données ou utiliser une base de données en mode PAAS.

Pour lancer le déploiement, il faut au préalable créer un secret ( fait manuellement pour ne pas stocker d’objet yaml dans le repository GITHUB) pour se connecter au repo GITHUB via la commande suivante:

kubectl create secret docker-registry github-registry --docker-server=docker.pkg.github.com --docker-username=USER--docker-password=PASSWORD --docker-email=EMAIL

On peut faire pareil pour les connexions base de données. J’ai mis dans un configmap pour ne pas trop me prendre la tête…

Après le déploiement via le pipeline se fait assez simplement:

      [...]
      - uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
        with:
          version: '286.0.0'
          service_account_email: ${{ secrets.GKE_SA_EMAIL }}
          service_account_key: ${{ secrets.GKE_SA_KEY }}
          project_id: ${{ secrets.GKE_PROJECT }}
      # Get the GKE credentials so we can deploy to the cluster
      - run: |-
          gcloud container clusters get-credentials "${{ secrets.GKE_CLUSTER }}" --zone "${{ secrets.GKE_ZONE }}"
      # Deploy the Docker image to the GKE cluster
      - name: Deploy
        run: |-
          kubectl apply -f ./k8s

J’utilise les « actions » fournies par Google.

Conclusion

Pour que ça marche il y a pas mal d’étapes préalables ( des tokens à générer, un utilisateur technique, …).
J’ai essayé de les référencer dans le README du projet.
Si vous voulez tester l’intégration Kubernetes dans le cloud google, sachez que vous pouvez disposer d’un crédit de 300€ valable un an. Attention, avec ce genre d’architecture, ça part vite…

Original post of Littlewing.Votez pour ce billet sur Planet Libre.

PROJET AUTOBLOG