DEV Community: David YOTEAU

Exploration de l'API Standard de Crystal-lang PART 4 (Class)

David YOTEAU — Fri, 14 Jul 2023 12:36:51 +0000

Introduction

Dans cette quatrième partie, nous allons encapsuler la partie serveur HTTP dans une classe dédiée.

C'est partie.

Etats des lieux

Notre fichier principal ressemble à ça

require "http/server"
require "./singleton"
require "./config"
require "./repository"

# Define a route for the todo list page.
server = HTTP::Server.new() do |context|
  request = context.request

  case request.path
  when "/"
    items = Repository.new(Config::TODO_FILE_PATH).all
    context.response.content_type = "text/html"
    context.response.print(ECR.render "src/template.ecr")
  when "/add"
    if request.method == "POST"
      body = request.body
      if body.nil?
        context.response.status_code = 400
        context.response.print("Body is required")
      else
        params = body.gets_to_end
        uri_params = URI::Params.parse(params)
        item = uri_params.fetch("item",nil)
        if item.nil?
          context.response.status_code = 400
          context.response.print("Body is required")
        else
          Repository.new(Config::TODO_FILE_PATH).add(item)
        end
        context.response.status_code = 302
        context.response.headers["Location"] = "/"
      end
    else
      context.response.status_code = 405
      context.response.headers["Allow"] = "POST"
      context.response.print("Method not allowed")
    end
  else
    context.response.status_code = 404
    context.response.print("Not found")
  end
end

server.bind_tcp Config::BIND_IP, Config::PORT
if Config.environment != "test"
  server.listen
end

Dans un premier temps, notre but va être d'isoler la partie serveur dans un objet.

Vision objet

Notre serveur est défini par :

ce qu'il écoute : des requêtes au protocol HTTP sur une connexion TCP_IP (IP, PORT)
ce qu'il renvoie.

Nous allons traiter la première partie.

Passons aux tests.

Quand nous initialisons le serveur HTTP, nous avons besoin de définir l'ip et le port d'écoute. Nous avons aussi besoin que cela fonctionne sans cette saisie. Créons le fichier ./spec/server_spec.cr

require "./spec_helper"

describe Server do
  describe "#new" do
    it "set default ip at 0.0.0.0" do
      Server.new.bind_ip.should eq "0.0.0.0"
    end
    it "set default port at 3000" do
      Server.new.port.should eq 3000
    end
    it "set bind_ip with argument value" do
      Server.new(bind_ip: "254.43.35.34").bind_ip.should eq "254.43.35.34"
    end 
    it "set port with argument value" do
      Server.new(port: 4567).port.should eq 4567
    end   
    it "set ip and port with argument value" do
      server = Server.new(bind_ip: "123.123.123.123", port: 9876)
      server.bind_ip.should eq "123.123.123.123"
      server.port.should eq 9876
    end     
  end 
end

Ces tests sont simples mais permettent de montrer la syntaxe de Crystal sur les signatures de méthodes. En passant, dans la signature, le nom des variables de celle-ci, je me permets de laisser le choix de l'implémentation pour plus tard.
En revanche, cela impose d'avoir des valeurs par défaut dans notre implémentation.

Implémentation de notre objet `Server`

L'ip et le port d'écoute n'ont pas besoin d'être changé après l'initialisation. Je propose donc de ne définir que des getter.
La partie serveur n'a pas à être exposé en dehors de la classe à mon humble avis.
L'implémentation donne alors :

class Server
  getter bind_ip : String
  getter port : Int32

  def initialize(@bind_ip = "0.0.0.0", @port = 3000)
    @server = HTTP::Server.new() do |context|
      request = context.request

      case request.path
      ...
      end
    end
  end

  def run
    @server.bind_tcp @bind_ip, @port
    @server.listen
  end
end

getter est une macro qui va définir la méthode def bind_ip ...

Si nous avions mis un setter, cela aurait défini la méthode def bind_ip=. Le la macro property réalise les deux.

Ensuite, dans la signature de la méthode initialize, nous pouvons mettre directement les variables de classe en lieu et place de :

def initialize(bind_ip)
  @bind_ip = bind_ip
end

et pour définir une valeur par défaut, nous pouvons le faire dans la signature comme je l'ai fait ici.

Note importante , si une variable de classe est obligatoire (ne peut être nulle), le compilateur vérifiera que cette variable est bien renseignée à la fin de la méthode initialize. Si ce n'est pas le cas, une erreur de compilation apparaîtra.

Conclusion

Cette partie est courte mais je voulais revenir sur l'initialisation d'un objet et l'importance de la signature de la méthode initialize

Dans la prochaine partie, nous allons nous attaquer à la partie routage. Pour cela, nous allons avoir besoin d'utiliser les REGEX.

Exploration de l'API Standard de Crystal-lang PART 3 (Class)

David YOTEAU — Wed, 12 Jul 2023 16:45:51 +0000

Introduction

Partie 3 : Encapsulons les méthodes liées à la persistance des données dans une classe.

C'est parti.

Etat des lieux

Pour l'instant, nous gérons nos accès à la persistance via 2 méthodes écrites sur le Top level.

def add_task(item : String)
  file = File.open(Config::TODO_FILE_PATH, "a")
  file.puts item
  file.close
end

def task_list : Array(String)
  File.read_lines(Config::TODO_FILE_PATH)
end

Vision Objet.

Si nous regardons ça sous la vision d'un objet, notre persistance est un Repository que l'on initialise avec le chemin d'accès. Puis nous aurons besoin des méthodes d'ajout d'un élément au dépôt et de lister ce que contient le dépôt.

Passons aux tests

Pour l'initialisation, nous voulons passer un chemin en argument. La vérification sera que le chemin est bien renseigné et que le fichier existe. Puis nous supprimerons le fichier pour la ré-utilisabilité du test.

  describe "#new" do
    it "initialize Repository with given path" do
      path = File.join(Dir.current,"spec", "fixtures", "repo", "new.txt")
      repo = Repository.new(path: path)
      repo.path.should eq path
      File.exists?(path).should eq true
      File.delete(path)
    end
  end

Pour la méthode de remontée de la liste des éléments, nous allons créer un fichier all.txt dans ./spec/fixtures/repo. Nous valorisons le fichier avec 3 lignes.

test
all
method

et le test comme suit

  describe "#all" do
    it "return a list for a given file" do
      path = File.join(Dir.current,"spec", "fixtures", "repo", "all.txt")
      repo = Repository.new(path)
      repo.all.should eq ["test","all","method"]
    end
  end

Enfin, pour l'ajout, nous initialisons un repo vide. Nous appelons notre méthode d'ajout. Puis vous vérifions que notre repo contient bien notre élément.

  describe "#add" do
    it "store todo into the given file" do
      path = File.join(Dir.current, "spec", "fixtures", "repo", "add.txt")
      repo = Repository.new(path)
      repo.add("test add method")
      repo.all.should eq ["test add method"]
      File.delete(path)
    end
  end

Le tout dans le fichier ./spec/repository_spec.cr, dans un describe global.
En résumé :

require "./spec_helper"

describe Repository do
  describe "#new" do
    it "initialize Repository with given path" do
      path = File.join(Dir.current,"spec", "fixtures", "repo", "new.txt")
      repo = Repository.new(path: path)
      repo.path.should eq path
      File.exists?(path).should eq true 
      File.delete(path)
    end
  end
  describe "#all" do
    it "return a list for a given file" do
      path = File.join(Dir.current,"spec", "fixtures", "repo", "all.txt")
      repo = Repository.new(path)
      repo.all.should eq ["test","all","method"]
    end
  end
  describe "#add" do
    it "store todo into the given file" do
      path = File.join(Dir.current, "spec", "fixtures", "repo", "add.txt")
      repo = Repository.new(path)
      repo.add("test add method")
      repo.all.should eq ["test add method"]
      File.delete(path)
    end
  end
end

Implémentation de notre `Repository`

Si nous lançons les tests en tant que tel, nous aurons plein d'erreur de méthodes et de classes non définies.

Écrivons le code minimum pour que les tests se lancent

class Repository
  getter path : String

  def initialize(@path)
  end

  def all
  end

  def add(element : String)
  end
end

La commande crystal spec s'executent maintenant sans erreurs et tous nos tests sont en échec.

crystal spec
.....FFF

Failures:

  1) Repository #new initialize Repository with given path
     Failure/Error: File.exists?(path).should eq true

       Expected: true
            got: false

     # spec/repository_spec.cr:9

  2) Repository #all return a list for a given file
     Failure/Error: repo.all.should eq ["test","all","method"]

       Expected: ["test", "all", "method"]
            got: nil

     # spec/repository_spec.cr:17

  3) Repository #add store todo into the given file
     Failure/Error: repo.all.should eq ["test add method"]

       Expected: ["test add method"]
            got: nil

     # spec/repository_spec.cr:25

Finished in 416 microseconds
8 examples, 3 failures, 0 errors, 0 pending

Failed examples:

crystal spec spec/repository_spec.cr:5 # Repository #new initialize Repository with given path
crystal spec spec/repository_spec.cr:14 # Repository #all return a list for a given file
crystal spec spec/repository_spec.cr:21 # Repository #add store todo into the given file

On voit ici l'importance du nommage des tests

Implémentation de l'init

Nous souhaitons que le chemin passé en argument corresponde à un fichier qui existe. Dans le cas contraire, nous le créons.

class Repository
...
  def initialize(@path)
    unless File.exists?(@path)
      file = File.new(@path,"wb")
      file.close
    end
  end
...

Le mode wb permet de créer le fichier et de s'assurer qu'il soit vide.

Implémentation de la méthode `all`

Nous avons besoin d'ouvrir le fichier correspondant au path et d'en lister le contenu. Nous pouvons reprendre le code d'origine et l'adapter à notre nouveau contexte.

class Repository
...
  def all
    File.read_lines(@path)
  end 
...

Implémentation de la méthode `add`

Comme ci dessus, nous adaptons l'existant.

class Repository
...

...

Execution des tests.

crystal spec
........

Finished in 473 microseconds
8 examples, 0 failures, 0 errors, 0 pending

Tout va bien.

Refactoring.

Etape 1 : Mettre notre nouvelle classe dans un fichier à part.

Nous prenons le code de notre class pour le mettre dans le fichier ./src/repository.cr et nous le remplaçons par require "./repository" dans notre fichier principal.

Etape 2 : Nous remplaçons les anciennes méthodes par notre classe.

    items = task_list

devient

    items = Repository.new(Config::TODO_FILE_PATH).all

          add_task(item)

devient

  Repository.new(Config::TODO_FILE_PATH).add(item)

Etape 3 : Nettoyage

Nous supprimons le code des anciennes méthodes.

Conclusion.

Nous avons vu comment créer une classe et la tester.

Dans la prochaine partie, nous allons encapsuler la partie serveur HTTP.

Exploration de l'API Standard de Crystal-lang PART 2 (Spec, ENV, Module)

David YOTEAU — Wed, 12 Jul 2023 09:57:37 +0000

Introduction

Voici la partie 2 de notre série. il est nécessaire d'avoir lu la partie précédente pour suivre cet article.

Dans cet article, nous allons voir :

Spec librairie interne de test
Les modules.
ENV Manipulation des variables d'environnement

C'est parti

lançons les tests - premier essai.

La commande de test est crystal spec. Cette commande va exécuter les test contenus dans tous les fichier _spec.cr de toutes l'arborescence ./spec/**/*.

Voici le code par défaut, qui a été généré avec le crystal init dans le fichier ./spec/web_spec.cr

describe Web do 
  # TODO: Write tests

  it "works" do
    false.should eq(true)
  end 
end

describe est un mot clé pour décrire une suite de test. Nous pouvons lui passer en argument soit une chaîne de caractère soit le nom d'un objet. Nous pouvons ecrire un autre bloc describe dans celui existant. Cela aura pour effet de se concaténer.

Dans notre cas, l'objet Web n'existe pas. la commande crystal spec va nous répondre une erreur.

it est le bloc de test. Nous lui passons une chaîne de caractère en argument. Chaîne qui doit décrire le test. Par convention, si le test concerne une méthode de l'objet passer en describe, nous préfixons le nom de la méthode par un #

Ensuite, nous pouvons voir que le test écrit est voué à l’échec false ne valant jamais true.

Corrigeons ces deux points et regardons ce qui ce passe...

Dans l'état actuel des choses, il ne se passera rien et votre crystal spec restera bloqué. Il faudra un CTRL+C pour sortir.

Voici ce qu'il se passe. Notre fichier ./spec/web_spec.cr charge le fichier ./spec/spec_helper.cr. Ce dernier charge notre code du fichier ./src/web.cr. Or, notre code lance un serveur HTTP et attend en boucle les requêtes. C'est ce qui bloque notre test.

Deux solutions s'offre à nous pour l'instant.

Rapide : Nous sortons la commande server.listen dans un autre fichier. Et nous lancerons ce nouveau fichier quand nous voudrons lancer le serveur.

Par configuration : Nous conditionnons le lancement de server.listen au fait de ne pas être en environnement de test.

Dans notre cas, nous partons sur la première solution pour évoluer vers la seconde.

Testons notre configuration.

Dans le code actuel, nous avons quelques constantes au début :

TODO_FILE_PATH = File.join(Dir.current, "todo.txt")

et quelques valeurs en dur pour la configuration de notre serveur http

server.bind_tcp "0.0.0.0", 8080

et comme nous venons de le voir, nous avons aussi besoin de déterminer dans quel environnement nous sommes.

Supprimons le fichier ./spec/web_spec.cr qui ne nous sert pas. Créons un fichier ./spec/config_spec.cr.

Commençons l’écriture de notre test, nous avons besoin d'un objet qui va stocker notre configuration et permettre un accès dans tout notre code.

La première constante va être TODO_FILE_PATH.

require "./spec_helper"

describe Config do
  describe "#TODO_FILE_PATH" do
    pending "return a path by concat current dir with 'todo.txt' do
    end
  end
end

le mot clé pending permet ne pas exécuter ce test tout en gardant la structure pour plus tard.

Passons à l’écriture du test et du module

  require "./spec_helper"

  describe Config do
    describe "#TODO_FILE_PATH" do
      it "return a path by concat current dir and todo_file_name" do                             
        Config::TODO_FILE_PATH.should eq File.join(Dir.current, "todo.txt")
      end
    end
  end

ce qui se résout par le code suivant :

  module Config
    TODO_FILE_PATH = ENV.fetch("TODO_FILE_PATH", File.join(Dir.current, "todo.txt"))
  end

Crystal vient avec la librairie standard ENV qui permet de lire et de manipuler les variables d'environnement.

J'ai écris le code du module config dans le fichier src/web.cr. Nous allons le déplacer dans son propre fichier src/config.cr et le charger dans son fichier d'origine.

# src/web.cr
require "http/server"
require "./config"
...

On remplace toutes les occurrences de TODO_FILE_PATH par Config::TODO_FILE_PATH

Continuons avec les variables du serveur http et l'environnement.

Le test

  require "./spec_helper"

  describe Config do
    describe "#TODO_FILE_PATH" do
      it "return a path by concat current dir and todo_file_name" do
        Config::TODO_FILE_PATH.should eq File.join(Dir.current, "todo.txt")
      end
    end

    describe "#environment" do
      it "return development as default environment" do
        ENV.delete("GTD_ENVIRONMENT")
        Config.environment.should eq "development"
      end
      it "return passed value as environment" do
        ENV["GTD_ENVIRONMENT"]= "test"
        Config.environment.should eq "test"
        ENV.delete("GTD_ENVIRONMENT")
      end
    end

    describe "#PORT" do
      it "return default port" do
        Config::PORT.should eq 3000
      end
    end

    describe "#BIND_IP" do
      it "return default binding" do
        Config::BIND_IP.should eq "0.0.0.0"
      end
    end
  end

le module

  module Config
    TODO_FILE_PATH = ENV.fetch("TODO_FILE_PATH", File.join(Dir.current, "todo.txt"))
    PORT = ENV.fetch("PORT", "3000").to_i
    BIND_IP = ENV.fetch("BIND_IP", "0.0.0.0")

    def self.environment
      ENV.fetch("GTD_ENVIRONMENT", "development")
    end
  end

tous les tests sont passant.

Lancement du serveur sauf pour les tests.

Revenons à notre deuxième solution de gestion du lancement du serveur maintenant que nous avons le module de configuration.

Supprimons le fichier créer pour la première solution.

Puis, à la fin du fichier src/web.cr ajoutons notre condition de lancement.

  server.bind_tcp Config::BIND_IP, Config::PORT
  if Config.environment != "test"
    server.listen
  end

Si nous lançons notre code avec crystal src/web.cr, nous avons bien notre application disponible via http://localhost:3000/

si je lance les tests avec la commande GTD_ENVIRONMENT=test crystal spec, les tests se lancent sans le serveur.

Il peut être lassant d'ajouter la variable d'environnement à chaque lancement. Pour ma part, j'ai ajouté cette variable dans le fichier ./spec/spec_helper.cr comme suit :

  require "spec"
  ENV["GTD_ENVIRONMENT"]="test"
  require "../src/web"

Conclusion

Nous avons vu les bases de Spec, la manipulation de l'environnement via ENV et la forme d'objet Module.

Dans le prochain article, nous regrouperons les méthodes liées au dépôt de tâches au sein d'une classe

Note :

repository gitlab

Exploration de l'API Standard de Crystal-lang PART 1 (HTTP::Server, DIR, ECR, File)

David YOTEAU — Thu, 29 Jun 2023 15:37:10 +0000

Introduction Générale

Cette article est le premier d'une série. Cette série vise à explorer l'API standard de Crystal-lang à travers la réalisation d'une application.

L'application cible est un gestionnaire de la méthode "Getting Things Done" avec une partie web, une api HTTP et une CLI.

Cette article

Dans cette article en particulier, nous allons créer une page d'ajout de tâches et une persistance en fichier. Nous allons utiliser :

HTTP::Server pour exposer le service
ECR pour concevoir l'écran
File pour la persistance
Dir pour la gestion de l’arborescence

C'est parti

Créons des tâches dans un fichier.

Pour l'instant, la structure d'une tâche est une chaine de caractères, chaque ligne dans le fichier sera une tâche.

Définissons une constante pour le chemin vers le fichier de persistance.

TODO_FILE_PATH = File.join(Dir.current, "todo.txt")

Dir.current renvoie le chemin courant de l’exécutable.

File.join permet de créer le chemin en y ajoutant le nom du fichier voulu. Cette méthode prend autant d'élément que vous le souhaitez et va créer un chemin système valide en fonction de votre OS.

Maintenant que nous avons le chemin, nous allons écrire la méthode d'ajout de tâche au fichier.

def add_task(item : String)
  file = File.open(TODO_FILE_PATH, "a")
  file.puts item
  file.close
end

Nous pouvons aussi l'écrire sous cette forme

def add_task(item : String)
  File.open(TODO_FILE_PATH, "a") do |file|
    file.puts item
  end
end

Dans le deuxième cas, le File.close est implicitement exécuté à la fin du bloc File.open.

File.open va ouvrir le fichier avec le mode passé en argument. Par défaut, c'est le mode "r" pour "read". Vous avez aussi :

w pour write, créer ou remplace le fichier avec le contenu.
rw pour read-write, ouvre le fichier et remplace le contenu.
a pour append, ajoute le contenu à la fin du fichier.

Nous souhaitons ajouter une tâche, le choix se porte sur le mode "a".

File.puts envoie, à la fin du fichier, la chaîne de caractère passée en argument.

Avec ce que nous venons de voir, ajoutons une méthode pour récupérer la liste de toutes les tâches.

def task_list : Array(String)
  File.read_lines(TODO_FILE_PATH)
end

File.read_lines a l'avantage d'ouvrir le fichier, lire le contenu et le transforme en tableau puis refermer le fichier.

Nous en avons fini avec la persistance pour cette article. Passons à la partie mise en page.

Créons un écran html.

Pour faire un template et embarquer du code crystal, l'API standard fournit ECR.

Dans son mode d'usage le plus simple, il faut :

définir des variables
exécuter un ECR.render avec le fichier template en argument. (Toutes les variables du même scope que le ECR.render seront transmises)

Dans notre cas, nous avons besoin de la liste des tâches (déjà réalisé ci-dessus) et du template. Nous sommes sur du web, il s'agit d'un template HTML.

  <!DOCTYPE html>
  <html>
    <head>
      <title>Todo List</title>
    </head>
    <body>
      <h1>Todo List</h1>
      <ul>
        <% items.each do |item| %>
          <li><%= item %></li>
        <% end %>
      </ul>
    </body>
  </html>

Je vous passe la partie HTML réduit à sa plus simple expression.

Pour ce qui nous intéresse, nous pouvons voir l'usage des balise <% %> et <%= %> pour l'insertion de code crystal. Ici, un simple parcours de la liste des items pour ensuite les afficher en liste HTML.

Voyons comment créer un serveur HTTP pour afficher cette page

Le serveur http.

Crystal-lang vient avec un serveur http dans son API standard.

le code de la documentation est

require "http/server"

server = HTTP::Server.new do |context|
  context.response.content_type = "text/plain"
  context.response.print "Hello world!"
end

address = server.bind_tcp 8080
puts "Listening on http://#{address}"
server.listen

Nous voyons que nous avons un HTTP::Context qui est à disposition. Cette objet contient la requête et permet de définir la réponse. A minima, nous devons définir le content-type et le body.

Une fois la gestion du contexte établi, nous pouvons configurer l'ip et le port d'écoute puis lancer l’écoute.

dans notre cas, nous voulons afficher notre page quand la requête est sur le chemin "/".

require "http/server"

server = HTTP::Server.new do |context|
  request = context.request

  case request.path
  when "/"
    items = task_list
    context.response.content_type = "text/html"
    context.response.print(ECR.render "src/template.ecr")
  else
    context.response.status_code = 404
    context.response.print("Not found")
  end
end

address = server.bind_tcp 8080
puts "Listening on http://#{address}"
server.listen

En lançant l'application, vous aurez votre liste de tâches. Pour l'exemple, je vous conseille de créer un fichier "todo.txt" à la racine de votre projet et d'y ajouter des lignes.

Passons à la possibilité d'ajouter des tâches via notre IHM.

Ajout du formulaire

reprenons notre template et ajoutons un formulaire simple d'envoi du texte de la tâche.

  <!DOCTYPE html>
  <html>
    <head>
      <title>Todo List</title>
    </head>
    <body>
      <h1>Todo List</h1>
      <ul>
        <% items.each do |item| %>
          <li><%= item %></li>
        <% end %> 
      </ul>
      <form method="post" action="/add">
        <label for="item">New item:</label>
        <input type="text" id="item" name="item">
        <button type="submit">Add</button>
      </form>
    </body>
  </html>

L'ajout d'une tâche passe par une requête POST sur le chemin "/add".

Reprenons notre serveur pour en ajouter la gestion de cet appel.

...
  server = HTTP::Server.new() do |context|
    request = context.request

    case request.path
    when "/" 
      items = task_list
      context.response.content_type = "text/html"
      context.response.print(ECR.render "src/template.ecr")
    when "/add"
      if request.method == "POST"
        body = request.body
        if body.nil?
          context.response.status_code = 400 
          context.response.print("Body is required")
        else
          params = body.gets_to_end
          uri_params = URI::Params.parse(params)
          item = uri_params.fetch("item",nil)
          if item.nil?
            context.response.status_code = 400 
            context.response.print("Body is required")
          else
            add_task(item)
          end 
          context.response.status_code = 302 
          context.response.headers["Location"] = "/" 
        end 
      else
        context.response.status_code = 405 
        context.response.headers["Allow"] = "POST"
        context.response.print("Method not allowed")
      end 
    else
      context.response.status_code = 404 
      context.response.print("Not found")
    end 
  end
...

Oui, je sais, beaucoup de bloc if et case imbriqué. Ce code est là pour gérer les différentes erreurs sans utiliser de lib externes.

La nouveauté de ce bloc est URI::params.parse qui récupère les objet du formulaire à partir de la lecture du body de la requête.

Voici ce qui termine ce premier article.

Conclusion.

Nous avons vu File, Dir, HTTP::Server et ECR. Dans la suite, nous allons voir comment tester tout ça.

Prochaine API : Spec

Note :

repository gitlab

Traefik 2 : Let's encrypt and HTTPS redirection

David YOTEAU — Tue, 10 Sep 2019 21:09:39 +0000

Traefik 2: Let's encrypt and redirect HTTPS

This article follows these articles:

The need

I need :

to publish a HTTPS site
to have a valid certificate
to redirect the HTTP stream on the HTTPS.

Let's encrypt

So let's add Let's encrypt ascertificatesResolvers of Traefik.
For this, we need :

a contact email address for Let's encrypt
to choose the format and file of the certificate storage
to choose the challenge mode used byLet's encrypt for creation and renewal.

In my case, I use the same acme.json file that I had for Traefik V1. You can create a blank if you start from scratch.
For challenge mode, I prefer HTTP because it allows me to do everything from Traefik.

Now I can add my block to the traefik.yaml file

certificatesResolvers:
  letsencrypt:
    acme:
      email: "jade.kharats@example.tld"
      storage: acme.json
      httpChallenge:
        entryPoint: http

And to share this file between my Traefik instances, I need to add it in volume in stack-traefik.yml

services:
  traefik:
    volumes:
      - /swarm/traefik2/acme.json:/acme.json

From now, Traefik will generate a certificate for the domains that are requested.
Let's go certificate our dashboard.

TLS

I will add a router on the entryPoint https. On this router, I will enable TLS and tell it to use Let's encrypt as resolver.

it's happening in stack-traefik.yml

services:
  traefik:
    deploy:
      labels:
        - "traefik.http.routers.traefik-router.entrypoints=https"
        - "traefik.http.routers.traefik-router.rule=Host(`traefik.example.tld`)"
        - "traefik.http.routers.traefik-router.tls=true"
        - "traefik.http.routers.traefik-router.tls.certresolver=letsencrypt"

After a deployment of the new version, I have my domain served in https with a valid certificate. Simple, no?

HTTPS redirection

Why continue to allow access in HTTP while we have our HTTPS available? We will want to redirect the stream.
Traefik 2 provides a middleware for that.

Another label to put in our stack-traefik.yml

services:
  traefik:
    deploy:
      labels:
        - "traefik.http.routers.traefik-router0.entrypoints=http"
        - "traefik.http.routers.traefik-router0.rule=Host(`traefik.example.tld`)"
        - "traefik.http.routers.traefik-router0.middlewares=traefik-redirectscheme,auth"
        - "traefik.http.middlewares.traefik-redirectscheme.redirectscheme.scheme=https"

So we added "traefik.http.middlewares.traefik-redirectscheme.redirectscheme.scheme=https" to define the redirection.
I called this middleware traefik-redirectscheme but I risk using it for other routers than those of Traefik. I would change the name on this occasion.
I then add this middleware to the list of middleware of my router0
And voila.

Conclusion

It's easy to manage the HTTPS and TLS part with Traefik 2.

One of the great assets of this second version is the addition of TCP management.
In the following article, I will set up a GITEA server with an HTTPS router and a TCP router.

traefik.yaml

global:
  checkNewVersion: true
  sendAnonymousUsage: true
api:
  dashboard: true
  debug: true
entryPoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"
providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIP: true
    endpoint: "unix:///var/run/docker.sock"
certificatesResolvers:
  letsencrypt:
    acme:
      email: "jade.kharats@example.tld"
      storage: acme.json
      httpChallenge:
        entryPoint: http
log:
  filePath: "log/traefik.log"
  level: WARN
accessLog:
  filePath: "log/access.log"
  bufferingSize: 100

stack-traefik.yml

version: "3.3"

networks:
  traefik-net:
    external: true

configs:
  traefik.yaml:
    file: ./traefik.yaml


services:
  traefik:
    image: traefik:v2.0
    ports:
      - 80:80
      - 443:443
      - 22:22
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /swarm/traefik2/acme.json:/acme.json
      - /swarm/traefik2/log:/log
    configs:
      - source: traefik.yaml
        target: /etc/traefik/traefik.yaml

    networks:
      - traefik-net
    deploy:
      mode: global
      placement:
        constraints: [node.role == manager]
      labels:
        - "traefik.docker.network=traefik-net"
        - "traefik.http.routers.traefik-router0.entrypoints=http"
        - "traefik.http.routers.traefik-router0.rule=Host(`traefik.example.tld`)"
        - "traefik.http.routers.traefik-router0.middlewares=traefik-redirectscheme,auth"
        - "traefik.http.routers.traefik-router.entrypoints=https"
        - "traefik.http.routers.traefik-router.rule=Host(`traefik.example.tld`)"
        - "traefik.http.routers.traefik-router.tls=true"
        - "traefik.http.routers.traefik-router.tls.certresolver=letsencrypt"
        - "traefik.http.routers.traefik-router.middlewares=auth"
        - "traefik.http.middlewares.traefik-redirectscheme.redirectscheme.scheme=https"
        - "traefik.http.middlewares.auth.basicauth.users=jade:$$2y$$..."
        - "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

Traefik 2 : Contribution and Debug

David YOTEAU — Tue, 10 Sep 2019 20:26:42 +0000

Traefik 2 : Contribution and Debug

This article is a follow-up to this one: https://dev.to/jadekharats/traefik-2-concept-3elj

The need

We need to add other services to our Traefik but especially to understand how it works to learn.

Debugging and logging

Everything will be done in the static configuration. Besides, I give you the link to the official documentation of the static configuration by file: https://docs.traefik.io/v2.0/reference/static-configuration/file/

Log activation

In the traefik.yaml file we will add this block

log:
  filePath: "log/traefik.log"
  level: WARN

The WARN level is enough for my taste to understand the creations and configurations of Traefik 2 elements.

We will also add access.log that we find for any reverse proxy

AccessLog:
  filePath: "log/access.log"
  bufferingSize: 100

Activate the debug mode of the API

To have the API actions in the log/traefik.log log file, modify the api block as follows

api:
  dashboard: true
  debug: true

Recovery of logs outside the container

We want to get the logs out of the container. For that, nothing more simple, it is enough to declare the volume in the file stack-traefik.yml

services:
  traefik:
    volumes:
      - /swarm/traefik2/log:/log

Update and anonymous contribution.

Traefik 2 is in Release Candidate version. It is therefore necessary to keep up to date and at the same time, allow Traefik to send anonymous data to the maintainers to help them develop the RC.
Again, it's in the traefik.yaml that it's happening.

global:
  checkNewVersion: true
  sendAnonymousUsage: true

Conclusion.

Here we are ready for adding TLS and certificate generation.

As for the previous article, I put back, the state of the files at this stage.

traefik.yaml

global:
  checkNewVersion: true
  sendAnonymousUsage: true
api:
  dashboard: true
  debug: true
entrypoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"
providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIP: true
    endpoint: "unix:///var/run/docker.sock"
log:
  filePath: "log/traefik.log"
  level: WARN
AccessLog:
  filePath: "log/access.log"
  bufferingSize: 100

stack-traefik.yml

version: "3.3"

Link:
  traefik-net:
    external: true

configs:
  traefik.yaml:
    file: ./traefik.yaml


services:
  traefik:
    image: traefik:v2.0
    ports:
      - 80:80
      - 443:443
      - 22:22
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /swarm/traefik2/log:/log
    configs:
      - source: traefik.yaml
        target: /etc/traefik/traefik.yaml

    Link:
      - traefik-net
    deploy:
      fashion: global
      placement:
        constraints: [node.role == manager]
      labels:
        - "traefik.docker.network=traefik-net"
        - "traefik.http.routers.traefik-router0.entrypoints=http"
        - "traefik.http.routers.traefik-router0.rule=Host(`traefik.example.tld`)"
        - "traefik.http.routers.traefik-router0.middlewares=auth"
        - "traefik.http.middlewares.auth.basicauth.users=jade:$$2y$$..."
        - "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

Traefik 2 : Concept (VF)

David YOTEAU — Tue, 10 Sep 2019 19:58:40 +0000

Traefik 2 : Concept

Description

Traefik est un reverse proxy qui fait aussi load balancer. La version 1 était très facile à mettre en place sur un docker swarm.

Le besoin

De manière générale, nous avons besoin de déployer des conteneurs et qu'ils soient accessible par un nom de domaine par exemple.

Si on décompose ce besoin, nous avons donc :

un service qui écoute sur cette ip et sur un ou plusieurs ports
un service qui certifie les transactions
un service de gestion des certificats
un service de redirection des requêtes (HTTP ou TCP) vers le bon conteneur.

Pour tout ça, on a Traefik v2

Les éléments de Traefik v2

Les configurations

Traefik gère deux type de configurations : Dynamique ou Statique.
Pour la partie statique, je fais le choix d'un fichier traefik.yaml.
La partie dynamique est géré par des labels positionnés au niveau des conteneurs.

Les providers

Traefik a besoin de connaitre qui lui fournira sa configuration dynamique appelé providers

Dans mon cas, il s'agit d'un docker en mode swarm. J'ajoutes donc ceci au traefik.yaml

providers:
  docker:
    watch: true
    swarmMode: true
    endpoint: "/unix:///var/run/docker.sock"

Les entryPoints

Les entryPoints sont les couples ip:port sur lesquels Traefik va se mettre en écoute. C'est une configuration statique.

entryPoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"

Attention : Traefik fonctionne en convention over configuration. Si vous ne precisez pas d'entryPoints pour vos routeurs, il prendra le premier de la liste par défaut.
Pour ma part, je les ai mis par ordre de numéro de port pour le lire plus facilement.

Les routeurs

Les routeurs peuvent être statique mais sont géré en dynamique dans mon cas.
Un routeur a besoin d'un ou plusieurs entryPoints et de règle pour determiner quel routeur Traefik doit suivre.

Prenons l'exemple d'exposition du dashboard treafik pour la suite de l'article.

Nous allons écouter les requêtes sur le port 80 qui auront dans le header : host("traefik.example.tld")

Il faut donc ajouter les labels suivant à notre conteneur traefik :

- "traefik.http.routeurs.traefik-routeur0.entryPoints=http"
- "traefik.http.routeurs.traefik-routeur0.rule=Host(`traefik.example.tld`)"

Les services

Le service se configure facilement puisqu'il s'agit du conteneur qui porte les labels.
Traefik va déduire beaucoup de chose à partir de ça.

Maintenant, je vais vous montrer comment spécifier le réseau sur lequel Traefik doit chercher l'ip du conteneur et comment lui préciser le port.

Par défaut, j'ajoutes toujours les conteneurs, qui doivent être exposé via Traefik, au réseau traefik-net. C'est une habitude aquise en V1.

Dans les labels du conteneur, je vais donc lui préciser de prendre l'ip qui concerne ce réseau

- "traefik.docker.network=traefik-net"

Ensuite je vais lui préciser le port pour le service du dashboard. Mais voilà, Traefik 2 ne permet pas de le faire sans activation au niveau du provider docker.
Dans le fichier traefik.yaml, je modifie le bloc providers comme suit :

providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIp: true
    endpoint: "/unix:///var/run/docker.sock"

Ce qui permet d'ajouter le label suivant

- "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

Bien sûr, il faut aussi demandé à Traefik d'exposer son dashboard, ce qui se fait dans le traefik.yaml

api:
  dashboard: true

A partir de là, en lançant le service traefik, on pourrait déjà accéder à notre dashboard. Mais tout est public.
Heureusement, Traefik fournit un moyen d'ajouter des traitements intermédiaire via les middlewares.

Les middlewares

Il en existe de toute sorte mais dans un premier temps, je vais vous montrer comment ajouter un basic auth. Puis ajouter le middleware à un routeur.

La configuration d'un middleware peut se faire en statique ou en dynamique. J'ai longuement réfléchis sur l'endroit ou configurer ce middleware.
Puis j'ai finis par me dire que tous les éléments Traefik doivent être configurer en dynamique.

Du coup, j'ai ajouter ce label à mon conteneur Traefik

- "traefik.http.middlewares.auth.basicauth.users=titi:$$2y..."

Et pour l'ajouter à mon routeur

- "traefik.http.routeurs.traefik-routeur0.middlewares=auth"

Conclusion

Voilà pour le premier démarrage de mon Traefik v2 sur mon Swarm avec un configuration basique.

Dans l'article suivant, je détaillerais mes fichiers traefik.yaml et stack-traefik.yml pour la redirection https ainsi que la gestion de certificat.
En attendant, je vous pose le contenu des deux fichiers en dessous.

traefik.yaml

api:
  dashboard: true
entryPoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"
providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIP: true
    endpoint: "unix:///var/run/docker.sock"

stack-traefik.yml

 version: "3.3"

 networks:
   traefik-net:
     external: true

 configs:
   traefik.yaml:
     file: ./traefik.yaml


 services:
   traefik:
     image: traefik:v2.0
     ports:
       - 80:80
       - 443:443
       - 22:22
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro
     configs:
       - source: traefik.yaml
         target: /etc/traefik/traefik.yaml
     networks:
       - traefik-net
     deploy:
       mode: global
       placement:
         constraints: [node.role == manager]
       labels:
         - "traefik.docker.network=traefik-net"
         - "traefik.http.routers.traefik-router0.entrypoints=http"
         - "traefik.http.routers.traefik-router0.rule=Host(`traefik.kharats.fr`)"
         - "traefik.http.routers.traefik-router0.middlewares=auth"
         - "traefik.http.middlewares.auth.basicauth.users=titi:$$toto..."
         - "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

Traefik 2 : Concept

David YOTEAU — Tue, 10 Sep 2019 19:57:47 +0000

Traefik 2: Concept

Description

Traefik is a reverse proxy that is also load balancer. The first version was very easy to set up on a docker swarm.

The need

In general, we need to deploy containers and be accessible by a domain name for example.

If we break down this need, we have:

a service that listens on this ip and on one or more ports
a service that certifies transactions
a certificate management service
A request redirection service (HTTP or TCP) to the right container.

For all that, we have Traefik v2

The elements of Traefik v2

Configurations

Traefik manages two types of configurations: Dynamic or Static.
For the static part, I choose a traefik.yaml file.
The dynamic part is managed by labels positioned at the container level.

The providers

Traefik needs to know who will provide it with its dynamic configuration called providers

In my case, it is a docker in swarm mode. So I add this to traefik.yaml

providers:
  docker:
    watch: true
    swarmMode: true
    endpoint: "/unix:///var/run/docker.sock"

EntryPoints

The entryPoints are the ip:port pairs on which Traefik will listen. It's a static configuration.

entrypoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"

Warning: Traefik works in convention over configuration. If you do not specify entryPoints at your routers, by default, it will take the first one from list.
For my part, I put them in order of port number to read it more easily.

The routers

Routers can be static managed but are dynamically managed in my case.
A router needs one or more entryPoints and rule to determine which Traefik router should follow.

Take the example of the treafik dashboard exposition for the rest of the article.

We will listen to the requests on port 80 that will have in the header: host ("traefik.example.tld")

We must add the following labels to our traefik container:

- "traefik.http.routors.traefik-router0.entryPoints=http"
- "traefik.http.routeurs.traefik-router0.rule=Host(`traefik.example.tld`)"

Services

The service is easy to configure since it is the container that carries the labels.
Traefik will deduct a lot from that.

Now, I'm going to show you how to specify the network on which Traefik should look for the container ip and how to specify the port.

By default, I always add containers, which must be exposed via Traefik, to the traefik-net network. It is an acquired habit in V1.

In the labels of the container, I will tell him to take the ip concerning this network

- "traefik.docker.network=traefik-net"

Then I'll tell him the port for the dashboard service. But here, Traefik 2 does not allow to do without activation at the provider docker.
In the traefik.yaml file, I modify theproviders block as follows:

providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIp: true
    endpoint: "/unix:///var/run/docker.sock"

This allows to add the following label

- "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

Of course, Traefik must also be asked to exhibit his dashboard, which is done in traefik.yaml

api:
  dashboard: true

From there, by launching the traefik service, we could already access our dashboard. But everything is public.
Fortunately, Traefik provides a way to add intermediate processing via middleware.

The middlewares

There are all kinds but at first, I'll show you how to add a basic auth. Then add the middleware to a router.

The configuration of a middleware can be static or dynamic. I thought a lot about where to set up this middleware.
Then I end up telling myself that all Traefik elements must be dynamically configured.

So, I added this label to my container Traefik

- "traefik.http.middlewares.auth.basicauth.users=titi:$$2y..."

And to add it to my router

- "traefik.http.routeurs.traefik-router0.middlewares=auth"

Conclusion

So much for the first start of my Traefik v2 on my Swarm with a basic configuration.

In the following article, I will detail my traefik.yaml andstack-traefik.yml files for https redirection as well as certificate management.
In the meantime, I ask you the contents of the two files below.

traefik.yaml

api:
  dashboard: true
entrypoints:
  ssh:
    address: ":22"
  http:
    address: ":80"
  https:
    address: ":443"
providers:
  docker:
    watch: true
    swarmMode: true
    useBindPortIP: true
    endpoint: "unix:///var/run/docker.sock"

stack-traefik.yml

 version: "3.3"

 Link:
   traefik-net:
     external: true

 configs:
   traefik.yaml:
     file: ./traefik.yaml


 services:
   traefik:
     image: traefik:v2.0
     ports:
       - 80:80
       - 443:443
       - 22:22
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro
     configs:
       - source: traefik.yaml
         target: /etc/traefik/traefik.yaml
     Link:
       - traefik-net
     deploy:
       fashion: global
       placement:
         constraints: [node.role == manager]
       labels:
         - "traefik.docker.network=traefik-net"
         - "traefik.http.routers.traefik-router0.entrypoints=http"
         - "traefik.http.routers.traefik-router0.rule = Host (` traefik.kharats.fr`)"
         - "traefik.http.routers.traefik-router0.middlewares=auth"
         - "traefik.http.middlewares.auth.basicauth.users=titi:$$2y$$..."
         - "traefik.http.services.traefik-service.loadbalancer.server.port=8080"

DEV Community: David YOTEAU

Exploration de l'API Standard de Crystal-lang PART 4 (Class)

Introduction

C'est partie.

Etats des lieux

Vision objet

Passons aux tests.

Implémentation de notre objet Server

Conclusion

Exploration de l'API Standard de Crystal-lang PART 3 (Class)

Introduction

C'est parti.

Etat des lieux

Vision Objet.

Passons aux tests

Implémentation de notre Repository

Implémentation de l'init

Implémentation de la méthode all

Implémentation de la méthode add

Execution des tests.

Refactoring.

Etape 1 : Mettre notre nouvelle classe dans un fichier à part.

Etape 2 : Nous remplaçons les anciennes méthodes par notre classe.

Etape 3 : Nettoyage

Conclusion.

Exploration de l'API Standard de Crystal-lang PART 2 (Spec, ENV, Module)

Introduction

C'est parti

lançons les tests - premier essai.

Testons notre configuration.

Lancement du serveur sauf pour les tests.

Conclusion

Note :

Exploration de l'API Standard de Crystal-lang PART 1 (HTTP::Server, DIR, ECR, File)

Introduction Générale

Cette article

C'est parti

Créons des tâches dans un fichier.

Créons un écran html.

Le serveur http.

Ajout du formulaire

Conclusion.

Note :

Traefik 2 : Let's encrypt and HTTPS redirection

Traefik 2: Let's encrypt and redirect HTTPS

The need

Let's encrypt

TLS

HTTPS redirection

Conclusion

Traefik 2 : Contribution and Debug

Traefik 2 : Contribution and Debug

The need

Debugging and logging

Log activation

Activate the debug mode of the API

Recovery of logs outside the container

Update and anonymous contribution.

Conclusion.

Traefik 2 : Concept (VF)

Traefik 2 : Concept

Description

Le besoin

Les éléments de Traefik v2

Les configurations

Les providers

Les entryPoints

Les routeurs

Les services

Les middlewares

Conclusion

Traefik 2 : Concept

Traefik 2: Concept

Description

The need

The elements of Traefik v2

Configurations

The providers

EntryPoints

The routers

Implémentation de notre objet `Server`

Implémentation de notre `Repository`

Implémentation de la méthode `all`

Implémentation de la méthode `add`