What is TabNine​

TabNine is the ultimate development add-on, offering real-time code suggestions to help you achieve perfection in no time. And with an easy installation on Visual Studio Code, you can start playing your code symphony in no time.

TabNine is a programming virtuoso, understanding the context of your code to suggest the best lines of code. This can help you avoid common mistakes and write more efficient code. For example, if you are writing a piece of code to iterate through a list, TabNine can suggest the best options for traversing that list, such as the "for" loop or the "map" method.

TabNine is also a genius composer, always up to date with the latest development trends. This means that you can count on TabNine to offer you the best suggestions, no matter what version of your programming language you use. And with Visual Studio Code, you have a complete development environment to play your code symphony.

Translated with www.DeepL.com/Translator (free version)

Install TabNine​

To use TabNine with Visual Studio Code, just follow these simple steps:

• Open Visual Studio Code and go to the Extensions section.
• Search for TabNine in the list of available extensions.
• Click on Install to schedule the extension.
• Once the installation is complete, click on Activate to start using TabNine.
• To use TabNine, simply start typing code and select a code suggestion of the extension.

Once installed, you'll need to create a TabNine account to enjoy all the features of this development tool. It only takes a few minutes and will allow you to benefit from all the real-time suggestions and constant updates of TabNine. So don't wait any longer and add TabNine to your Visual Studio Code development environment today!

TabNine and Visual Studio Code are the perfect development tools to compose your code symphony. With real-time suggestions, contextual understanding, constant updates and a complete development environment, you can create epic pieces of development in no time. So don't wait any longer and let your passion for programming flow with TabNine and Visual Studio Code.

What is t?​

A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image. Using docker build users can create an automated build that executes several command-line instructions in succession.

Much like Vagrant that uses a vagrantfile to create and customize a virtual machine to your needs, Docker uses a dockerfile to create and customize a container! They may be similiar but they are very different! (you can learn how to use Vagrant to create a Windows Server vm here)

As meantion earlier, for this example, we're going to create a ruby container with mdl installed. So we need to start our dockerfile:

FROM ruby:latest

FROM creates a layer from the ruby latest Docker image.

Next:

FROM ruby:latest

WORDIR /mdl

WORDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile. If the WORKDIR doesn’t exist, it will be created even if it’s not used in any subsequent Dockerfile instruction.

Next:

FROM ruby:latest

WORDIR /mdl
RUN gem install mdl

RUN has 2 forms:

• RUN command (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux or cmd /S /C on Windows)
• RUN ["executable", "param1", "param2"] (exec form)

In our example, RUN executes a command that installs MDL directly in the ruby container

Next:

FROM ruby:latest

WORDIR /mdl
RUN gem install mdl

ENTRYPOINT [ "/bin/bash" ]

ENTRYPOINT, like RUN, has 2 forms! Shell form or exec form.

The exec form, which is the preferred form:

ENTRYPOINT ["executable", "param1", "param2"]

The shell form:

ENTRYPOINT command param1 param2

In our case, we're using it in exec form so we can execute our bash. This will leave our container open because bash is running in the background.

So, now that we have our dockerfile we have to build our container in order to run it!

docker build --tag user/mdl

The ---tag command names the image of the container in question. And now that the container is build we can run it!

For this will use the following command:

docker run -tid --name mdl -v /home/vagrant:/mdlfiles user/mdl

To be sure if your container is running properly do a simple docker ps -a just to have confirmation. Doing so will show you all of your containers details and status.

After confirming that the container is up and running we want to execute mdl to check our markdown file. To do so we'll need to run the mdl command inside a bash that will get the .md file inside the folder that we shared and named "mdlfiles"

docker exec mdl bash -c "mdl /mdfile/myfile.md"

If you have some inconsistencies regarding the rules of the mdl tool you'll get a result like this:

/mdfile/docker.md:5: MD009 Trailing spaces
/mdfile/docker.md:77: MD009 Trailing spaces
/mdfile/docker.md:25: MD012 Multiple consecutive blank lines
/mdfile/docker.md:51: MD012 Multiple consecutive blank lines
/mdfile/docker.md:13: MD013 Line length
/mdfile/docker.md:52: MD013 Line length
/mdfile/docker.md:54: MD013 Line length
/mdfile/docker.md:89: MD024 Multiple headers with the same content
/mdfile/docker.md:19: MD026 Trailing punctuation in header
/mdfile/docker.md:26: MD026 Trailing punctuation in header

After correcting all of them you should have no return after your command! :)

NOTE: if these command lines are confusing to you or you don't know what something means, please check my previous post.

Before you start​

Please, make sure that you checked my previous Docker post because I will be using some references to that post, and it would be easier to follow this post :)

In this case, will be using a ruby container to install our mdl tool. You show how to set up a ruby container in that previous Docker post that I mention.

Markdown Lint​

This is a tool for markdown (md) files that includes a library of rules to encourage standards and consistency for Markdown files and that confirms if the files are following theses rules.

Ruby container​

So, to start, lets run the ruby container! Copy paste the following line into your terminal:

docker run -tid -v /home/vagrant:/mdfiles --name ruby --entrypoint=/bin/bash ruby:latest

Okay, so you look at this command line and ask yourself what in the world is all of this!? Well, let me explain :)

The -tid is 3 different things:

• -t or --tty: Allocate a pseudo-TTY
• -i or --interactive: Keep STDIN open even if not attached
• -d or --detach: Detached mode: run command in the background

Afterwards, we do a -v for volume, that in our case, is used to mirror the folder where we have our .md file. This will allow us to have "the same folder" in our container. Remember that the / is root and then we create a new folder in the container named "mdfiles"

Then we use the --name and as the name suggest it's to attibute a name to your container.

We run --entrypoint /bin/bash to let a bash opened. This allows the container to stay opened (up) instead of closing just after the run. When you do an exec, it doesn't goes on bash (exec is sh and not bash). That's why we have to make the container run bash, to be able to use all the bash command

The difference between docker run and docker exec is that docker exec executes a command on a running container. On the other hand, docker run creates a temporary container, executes the command in it and stops the container when it is $So we use --entrypoint to run a container, and let it open until we decide to stop it

You can also give a command to your container directly by doing so: Note: If you have a windows container you use powershell instead of bash

docker exec ruby bash -c "ip add"

We execute the bash terminal with the command (-c) "ip add" This will show you the IP adress of your ruby container

And now we can install the mdl tool:

docker exec ruby bash -c "gem install mdl"

Great, everything looks nice and clean! Now, pick a .md file of your choosing, and run mdl:

docker exec ruby bash -c "mdl /mdfiles/myfile.md"

This will run the mdl tool through your md file and will inform you of how many errors you have, the lines they are and what was the rule that wasn't respected.

What is it??​

As explained in opensource.com Docker is a tool designed to make it easier to create, deploy, and run applications by using containers. Containers allow a developer to package up an application with all of the parts it needs, such as libraries and other dependencies, and deploy it as one package. By doing so, thanks to the container, the developer can rest assured that the application will run on any other Linux machine regardless of any customized settings that machine might have that could differ from the machine used for writing and testing the code.

In a way, Docker is a bit like a virtual machine. But unlike a virtual machine, rather than creating a whole virtual operating system, Docker allows applications to use the same Linux kernel as the system that they're running on and only requires applications be shipped with things not already running on the host computer. This gives a significant performance boost and reduces the size of the application.

How to use it​

In order to be able to run a container we need to have it available for us. So, to start we'll need to pull the wanted container and for this we will go to DockerHub.

For the sake of the example I'll use a Nginx and a Grafana containers.

Type in your terminal (where you runned your vagrantfile) the following command:

Nginx:

docker pull nginx

Check out the DockerHub Nginx page for more detail here

Grafana:

docker pull grafana/grafana

Check out the DockerHub Grafana page for more detail here

Now that we pulled the containers, they're "installed" in your machine so that you are able to use them.

But now we need to run our containers and we need to attribute them with specific ports. To do so we'll need to use the -p command.

So, let's check how do we run a container that we have available and how do we give it a port number of our choosing. For that, copy paste the following line in your terminal:

docker run -d --name=grafana -p 3000:3000 grafana/grafana

This will run Grafana in the port 3000. To confirm this we'll need to go to your brower and tyoe 127.0.0.1:3000 Doing so should open your personal Grafana's site.

Note that when you do -p 3000:3000 the second number is the designated port in your host. the option is "-p container_port_number:host_port_mapped" For example, if we do -p 3000:6000 then the ip for your grafana site will be 127.0.0.1:6000

TIP: If you did all of this and still got an error opening the web page, go check your VM preferences in VIrtualBox and make sure that you add port 3000 in the Port Redirections. To reach Port Redirections just open VirtaulBox, go to the Configuration of your Docker VM to the Network part. You'll find a Advance section and inside there will be the Port Redirection. VB > VM Configuration > Network > Advance > Port Redirection

Interrested ? Follow the guide!

[Update] Typora is not an open-source software, and only the beta version seems to be free. If taking habits on a free soft to later paid software bores you, we suggest using a open-source typora clone: MarkText.

Typora MarkText, From Markdown, with Love​

This tool is called typora, and the official site is there: typora MarkText

I present to you this tool that I will test for the series of articles around gitlab CI / CD.

It is available for Windows, Linux, and Mac OS.

Get the power of Markdown, without using Markdown​

The editor features provide you the power of the markdown format, because it is possible to save files directly in markdown, but also to copy the text in markdown format.

What You See Is What You Get​

Here is the article, in its french version, opened with typora. (MarkText would have the exact same result)

You can apply the style you want (Header 1-2-3, bold, etc. ) by selecting it in the menu, or using the standard shortcuts (CTRL+B, CTRL+I)

Save in Markdown​

You just have to save the file with marktext (only .md is authorized) or choose markdown with typora (which propose .txt too)

Export markdown content​

Typora MarkText let you export (or copy) a part of the document, directly with the markdown syntax.

Here is the result of the export with the french version of the article:

Un éditeur WYSIWYG pour éditSauvegarder au format MDer des fichiers Markdown ?

Si ça vous intrigue, suivez le guide !

# Typora, par amour du markdown

C'est outil s'appelle typora, et le site officiel est là: [typora](https://typora.io/)

Je vous présente cet outil que je vais tester pour la série d'article autour de gitlab CI/CD.

Il est disponible pour Windows, Linux, et en version beta (à l'heure d'acriture de ces lignes) pour Mac OS.

## Des fonctionnalités pour profiter de la puissance du markdown

Les fonctionnalités de l'éditeur permettent de profiter de la puissance du format markdown, car il est à la fois possible de sauvegarder des fichiers directement en markdown, mais également de copier le texte au format markdown.

### Un éditeur wysiwyg

Voici, par exemple, le rendu de cet article (dans sa version française)

You only have to select the part you want to export, and use the menu entry, or use the shortcut: CTRL + MAJ + C (the shortcut works on both typora and marktext)

Spell checker​

I assume that you know what I am talking about.

Markdown quality​

We use, to ensure quality of our markdown files syntax, a tool called markdownlint. The french version of the post got that result:

$ mdl content/posts/*.md --ignore-front-matter --rules ~MD013,~MD026,~MD033
content/posts/typora_fr.fr.md:13: MD009 Trailing spaces
content/posts/typora_fr.fr.md:15: MD009 Trailing spaces
content/posts/typora_fr.fr.md:21: MD009 Trailing spaces
content/posts/typora_fr.fr.md:23: MD009 Trailing spaces
content/posts/typora_fr.fr.md:27: MD009 Trailing spaces
content/posts/typora_fr.fr.md:39: MD009 Trailing spaces
content/posts/typora_fr.fr.md:45: MD009 Trailing spaces
content/posts/typora_fr.fr.md:47: MD009 Trailing spaces
content/posts/typora_fr.fr.md:50: MD009 Trailing spaces
content/posts/typora_fr.fr.md:52: MD009 Trailing spaces
content/posts/typora_fr.fr.md:58: MD009 Trailing spaces
content/posts/typora_fr.fr.md:60: MD009 Trailing spaces
content/posts/typora_fr.fr.md:64: MD009 Trailing spaces
content/posts/typora_fr.fr.md:75: MD009 Trailing spaces
content/posts/typora_fr.fr.md:81: MD009 Trailing spaces
content/posts/typora_fr.fr.md:82: MD009 Trailing spaces
content/posts/typora_fr.fr.md:84: MD009 Trailing spaces
content/posts/typora_fr.fr.md:96: MD009 Trailing spaces
content/posts/typora_fr.fr.md:100: MD009 Trailing spaces
content/posts/typora_fr.fr.md:109: MD009 Trailing spaces
content/posts/typora_fr.fr.md:35: MD012 Multiple consecutive blank lines
content/posts/typora_fr.fr.md:36: MD012 Multiple consecutive blank lines
content/posts/typora_fr.fr.md:90: MD012 Multiple consecutive blank lines
content/posts/typora_fr.fr.md:91: MD012 Multiple consecutive blank lines
content/posts/typora_fr.fr.md:105: MD012 Multiple consecutive blank lines
content/posts/typora_fr.fr.md:106: MD012 Multiple consecutive blank lines

The markdown syntax seems to be good. The only thing that isn't fixed by the tool is the rules that concern double spaces, spaces in the end of lines, double blank lines, etc.

In a word: everything that you can SEE on the wySiwyg.

The purpose of using Marktext/Typora​

Hugo websites posts​

typora MarkText is very usefull to write Hugo website text content, likes posts or authors descriptions.

For example, you can just copy the MD content in the gitlab/github web editor, paste it on Marktext, modify it, and copy as MD to re paste it on the gitlab/github editor.

You can also manage the content foder directly on the tool, but you'll have to use git in bash to push your modification on the gitlab/github repository:

Our tools​

We're using a set of tool based on (or compliant with) markdown:

• Wikis;
• Basecode READMEs;
• KB;
• ADR

The export tool (aka copy as markdown) is very useful to be able to edit text as in a standard texte editor, but being able to use the power of markdown when you want to change the structure of a text. This case commonly appears when editing a wiki or a kb pages. The more we add, the more we need to review the structure.

Conclusion​

I will start the articles about gitlab CI/CD with Marktext, and, to be honest, I truly think that I will get back to a MD editor.

But I have to confess that it is a great tool for those who want to get the power of markdown without learning/practicing the syntax. And I'm not totally sure that I will get back to a standard editor after I get habits on Marktext...

Chocolatey:​

Chocolatey is a module for windows to install packages (tools) on to the machine. Also known as a software management tool.

It allows us to perform various tasks via command line.

For example, "choco install tool" is the equivalent to "apt install tool" on Ubuntu.

So to install it you need to copy paste this command line to your terminal:

config.vm.provision "shell", inline: <<-SHELL

  Set-ExecutionPolicy Bypass -Scope Process -orce; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

SHELL

This command will install chocolatey and allow you to use "choco install" to install other tools into your windows machine such as Git or VSCode.

Example:​

You want to install some tools that you need and to do so you'll use Chocolatey!

So, in your terminal type any of the following commands:

choco install git -y
choco install vscode -y
choco install hugo -y

These commands will install the respective tools, but you can install the tools that you need. The only thing that you need to is choco install "tool that you want" :) Note, that the -y is to answer Yes to the questions asked by the installation process;

To start, lets try and understand what is what. We want to install a windows feature in our machine/vm and we want to do so by using Ansible to automate all the installations and add-ons.

To do so using Ansible we need to use Ansible modules! And, in this case, we want to use win_feature module. But what are modules? Lets see:

Modules​

Ansible modules are reusable, standalone scripts that can be used by the Ansible API, or by the ansible or ansible-playbook programs.

We can use modules to install, copy, move, download and a lot of others actions. There's also a lot of different modules, and I mean a lot!

Ansible has modules for Cloud, Database, Network, Monitoring, Windows, almost everything you can imagine!

But for this post we'll be focusing just on a specific windows module provided by Ansible that is win_feature module.

NOTE that this is just a quick overview of what modules are! You can check the official Ansible documetation on Modules to have a more in depth analyses.

win_feature​

This module installs or uninstalls Windows Roles or Features on Windows Server.

But, to know which feature we want to install we need to find its name. And for that we'll use a command that will list all of the features with the added information if they're installaed or not.

So type in your terminal the following:

Get-WindowsFeature

This should return a full list of the features:

PS C:\> Get-WindowsFeature

Display Name                                            Name                       Install State
------------                                            ----                       -------------
[ ] Active Directory Certificate Services               AD-Certificate                 Available
    [ ] Certification Authority                         ADCS-Cert-Authority            Available
    [ ] Certificate Enrollment Policy Web Service       ADCS-Enroll-Web-Pol            Available
    [ ] Certificate Enrollment Web Service              ADCS-Enroll-Web-Svc            Available
    [ ] Certification Authority Web Enrollment          ADCS-Web-Enrollment            Available
    [ ] Network Device Enrollment Service               ADCS-Device-Enrollment         Available
    [ ] Online Responder                                ADCS-Online-Cert               Available

(...)

[X] Web Server (IIS)                                    Web-Server                     Installed
    [X] Web Server                                      Web-WebServer                  Installed
        [X] Common HTTP Features                        Web-Common-Http                Installed
            [X] Default Document                        Web-Default-Doc                Installed
            [X] Directory Browsing                      Web-Dir-Browsing               Installed
            [X] HTTP Errors                             Web-Http-Errors                Installed
            [X] Static Content                          Web-Static-Content             Installed
            [X] HTTP Redirection                        Web-Http-Redirect              Installed
            [X] WebDAV Publishing                       Web-DAV-Publishing             Installed
        [X] Health and Diagnostics                      Web-Health                     Installed
            [X] HTTP Logging                            Web-Http-Logging               Installed
            [X] Custom Logging                          Web-Custom-Logging             Installed
            [X] Logging Tools                           Web-Log-Libraries              Installed
            [X] ODBC Logging                            Web-ODBC-Logging               Installed
            [X] Request Monitor                         Web-Request-Monitor            Installed
            [X] Tracing                                 Web-Http-Tracing               Installed
        [X] Performance                                 Web-Performance                Installed
            [X] Static Content Compression              Web-Stat-Compression           Installed
            [X] Dynamic Content Compression             Web-Dyn-Compression            Installed


(...)

[X] .NET Framework 4.7 Features                         NET-Framework-45-Fea...        Installed
    [X] .NET Framework 4.7                              NET-Framework-45-Core          Installed
    [ ] ASP.NET 4.7                                     NET-Framework-45-ASPNET        Available
    [X] WCF Services                                    NET-WCF-Services45             Installed
        [ ] HTTP Activation                             NET-WCF-HTTP-Activat...        Available
        [ ] Message Queuing (MSMQ) Activation           NET-WCF-MSMQ-Activat...        Available
        [ ] Named Pipe Activation                       NET-WCF-Pipe-Activat...        Available
        [ ] TCP Activation                              NET-WCF-TCP-Activati...        Available
        [X] TCP Port Sharing                            NET-WCF-TCP-PortShar...        Installed

(...)

Now we can see a full list of all Windows features (in the example above there's only a selected few) with the added information if they're installed or not.

This could be a great way to see what features do you need to add to your playbook.

Now, let me show you a way to find out if a a feature that you already know the name is installed or not.

For this case we'll search for the .NET Framework feature. We're going to check the feature correct name and if it's installed or not.

For that we'll use the command below:

Get-WindowsFeature | Where-Object {$_. name-match ".Net"} | Format-List Name,DisplayName, Installstate | more

This will return the following:

Name         : Print-Internet
DisplayName  : Internet Printing
InstallState : Available

Name         : Web-Net-Ext
DisplayName  : .NET Extensibility 3.5
InstallState : Installed

Name         : Web-Net-Ext45
DisplayName  : .NET Extensibility 4.7
InstallState : Installed

Name         : Web-Asp-Net
DisplayName  : ASP.NET 3.5
InstallState : Installed

Name         : Web-Asp-Net45
DisplayName  : ASP.NET 4.7
InstallState : Installed

Name         : NET-Framework-45-ASPNET
DisplayName  : ASP.NET 4.7                             #As you can see the feature is available, therefore not installed
InstallState : Available

Name         : BitLocker-NetworkUnlock
DisplayName  : BitLocker Network Unlock
InstallState : Available

Name         : Internet-Print-Client
DisplayName  : Internet Printing Client
InstallState : Available

Name         : Telnet-Client
DisplayName  : Telnet Client
InstallState : Available

Name         : WAS-NET-Environment
DisplayName  : .NET Environment 3.5
InstallState : Available

Name         : Wireless-Networking
DisplayName  : Wireless LAN Service
InstallState : Available

Now that we confirmed the name and the install state we can add to our playbook.yaml the win_feature module that we talked about earlier in the post.

Lets take a look at playbook.yaml containing the win_feature module

---
- name: Install Windows Features
  hosts: all
  tasks:
          - name: Install .Net Framework 4.5
            win_feature:
                    name: NET-Framework-45-ASPNET
                    state: present

As you can see, playbook.yaml will install the latest .Net Framework Windows feature.

Lets search for the .net Framework feature on our terminal and see what changed:

PS C:\> Get-WindowsFeature | Where-Object {$_. name-match "NET-Framework-45-ASPNET"} | Format-List Name,DisplayName, Installstate | more


Name         : NET-Framework-45-ASPNET
DisplayName  : ASP.NET 4.7
InstallState : Installed

And there it is! We successfully installed a windows feature of our choosing using Ansible playbooks!

Now, is up to you to see what Windows Feature do you wish to install on your server!

Remember that you can make a playbook installing as many features as you wish. I hope that this post will help you understand a bit better the win_feature module :)

To start lets take a look at a simple vagrantfile containing a Windows Server 2019 box:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

  SHELL

This is just to give you a visual of a very simple vagrantfile containing just the box, the name of the vm, RAM memory and a shell terminal ready to go.

Let's proceed!

Reload​

What's the use of reload ?

Well, using reload in your vagrantfile is the same as doing a reboot in your machine;

So, lets put this into context;

Say that we've installed Chocolatey and want to use it to install git.

Well that's easy, but we can't do it right away because since the vm was not reloaded (rebooted) it can't take into account the modification made previously;

So, to fix this, we need to add a reload provisioner to our vagrantfile!

config.vm.provision :reload

The above command is what we need to add to our vagrantfile but we can't use it if it's not installed.

So,to install the reload porvisioner open a Powershell terminal and type:

vagrant plugin install vagrant-reload

This will install the plugin that will allow you to use the reload provisioner on our vagrantfile;

Do you remember our simple vagrantfile ? Lets take a look of how the vagrantfile looks with the installation of Chocolatey:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

  SHELL

In our vagrantfile above, we install Chocolatey. But, remember, we want to use it to install our tools and without reloading the vm this won't be possible!

What we're going to do is, reload after installing Chocolatey and after reloading where going to open a new Shell terminal provisioner so we can install Git using Chocolatey;

So, lets take a look at our vagrantfile and see how all of this works put togheter:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

  SHELL

  config.vm.provision :reload

  config.vm.provision "shell", inline: <<-SHELL

    choco install git -y

  SHELL

Great! We achieved the installation of the plugin and the successful reload of our vm !

Disk Size​

Another usefull plugin is the Disk Size!

This plugin will allow us to manage the disk size of our vm (everybody who uses Vagrant knows that this is a sensible issue :) )

As seen previous, we first need to install the plugin directly to our machine so we can use it in our vagrantfile.

So, copy paste the following:

vagrant plugin install vagrant-disksize

Great, the plugin is installed and ready to be put to work!

Lets see how it looks:

config.disksize.size = '40GB'

As you can see, i want have a 40gb disk size. but where should we place it? Lets have a look at a basic vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

Very simple and basic vagrantfile but there's something missing! Where's the disk size?

Well, since it's a part of the configuration of the vm we will place it just after the vm box:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"
  wvm.disksize.size = "40GB"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

And there it is! You can now create vm's with the amount of disk size that you wish :)

NOTE: If you start your vm and see that your windows vm doesn't have the disk size you attributed and probably only have up to 20gb of disk size.

The other amount is not attributed to the right partition. To correct this we'll type the following command into a Powershell: (don't forget at the end of the command line to add your GB, in my case I gave 40gb so i'll put 39 at the end of the command)

Resize-Partition -DriveLetter C -Size 39gb

Hope to see you soon on the next post :)

It's quite unpleasant to have found THE perfect theme, and that a simple functionality is missing. So I decided to "trick", and use the native taxonomy management, in order to register several authors on a blog. And for the time being, it works pretty well.

To write this article, I was inspired by the following tutorial: How to create author pages.

I take care to complete it only on the points for which I had to experiment a lot.

Uses of taxonomies​

There are two standard taxonomies in Hugo:

• Tags;
• Categories.

To use Hugo's standard taxonomies, or those native to the chosen theme, it's very simple, you just have to add to your archetype the following elements:

---
tags:
- faire son site
- hugo-tips
categories:
- hugo
---

LThe principle is simple: as soon as you add a category or a tag, and the theme manages it well, you will find a page http://[votresite]/tags/ and another one called /catégories/ that list tags and categories, and a page per item listing the articles that mention the item in their archetypes.

Now let's see how to create a new taxonomy that would open the possibility to add one or more authors to an article.

Creating a taxonomy​

Each taxonomy has two templates:

• list.html, which corresponds to the template of the page that will describe one of the items (an author, for us, and all the articles linked to it)
• terms.html, which corresponds to the page that will list all the items of a taxonomy (all the authors, therefore)

In our case, we will create an author taxonomy. It will be post authors, and not book authors, as in the example of the previous link.

We are going to work in two tree structures:

• the content folder, logically at the root of the hugo site ;
• the layout folder of the theme used by the site.

The data concerning the items of the taxonomy​

In the content folder, we will create a folder for each author, in which a _index.md file will be placed,

content
└── authors/
    ├── j0rdan-m/
    │   └── _index.md
    └── author-2/
        └── _index.md

Each _index.md describes an author, and is composed as follows:

---
name: j0rdan-m
photo: 'https://j0rdan-m.gitlab.io/blog/pearlbonnet.png'
twitter: '@j0rdan_m'
---
j0rdan is an author of the blog

Meta-data​

The data concerning the authors are ready, now we have to set up the meta-data.

To do this, we will have to create an outside folder in the layout of our theme (and not the taxonomies folder, which may be surprising).

my_theme/
└── layout/
    └── authors/
        └── list.html
        └── terms.html

wThe list.html file does not list the authors, but the articles that mention the authors (or any other choice of taxonomy).

So, here is the basic content of the list.hml file:

<h1>{{ .Params.name }}</h1>
<img src="{{ .Params.photo }}" alt=""/>

<h2>Bio</h2>
{{ .Content }}
{{ with .Params.twitter }}
  <p>
    <a href="https://twitter.com/{{ substr . 1 }}">
      Follow {{ $.Params.name }} on Twitter
    </a>
  </p>
{{ end }}

<h2>Articles</h2>
<ul>
{{ range .Data.Pages }}
    <li><a href="{{ .Permalink }}">{{ .Title }}</a></li>
{{ end }}
</ul>

The terms.html file is the template of the page that will list all the authors, and propose a link for each one:

<h1>Authors</h1>
<ul>
{{ range .Data.Pages }}
  <li><a href="{{ .Permalink }}">{{ .Params.name }}</a></li>
{{ end }}
</ul>

Warning, it will be necessary to integrate upstream and downstream of the proposed codes the content of the theme, taking example on the default page (probably in themes/my_theme/layouts/_default/single.html)

The theme used by this blog offered a nice comment to isolate the theme info from the content (thanks to the <section></section> tag. Another theme I use mentions

Since we are on this single.html page, we will be able to add a mention of the authors:

{{- range .Params.authors }}
  {{- with $.Site.GetPage "taxonomyTerm" (printf "authors/%s" (urlize .)) }}
    <figure>
      <img src="{{ .Params.photo }}" alt=""/>
      <figcaption>
        <a href="{{ .Permalink }}">{{ .Params.name }}</a>
      </figcaption>
    </figure>
  {{ end }}
{{ end }}

This mention is to be added at the place of the page where you want it to appear, of course.

Finally, now that everything is ready, we can declare the taxonomy in our config.toml file, by adding the following note:

[taxonomies]
  author = "authors"
  tag = "tags"
  category = "categories"

On a personal note, I have manually added an entry in the menu, knowing that the viewing address of your taxonomy will be: http://[mon site]/authors/

So that's how, thanks to taxonomies, this blog became a multi-author blog.

Before we start, Plugins!​

Installation​

Windows​

So, to put in action some plugins into our Vagrantfile we need to installed them directly to our terminal.

To do so, open an Powershell and install the following plugins (note that this plugin is for Windows OS):

vagrant plugin install vagrant-reload

This will allow us to reload our vm during the creation of the vm.

Others OS​

Now, we want to use windows features but are using a Linux or MacOS.

For that, we need to install the following plugins in our Linux or MacOS machine:

vagrant plugin install vagrant-reload
vagrant plugin install winrm
vagrant plugin install winrm-fs
vagrant plugin install winrm-elevated

This will allow us to reload our vm and to use windows features with vagrant;

Now that we've have our plugins installed lets continue;

WSL​

What's WSL and what it does? WSL stands for Windows Subsystem for Linux and, by installing it on our Windows Server, it will allow us, basically, to have Linux on a Windows terminal.

Meaning that you can, for example, install a tool in your Windows vm using Linux commands like wsl sudo apt ansible -y (this command will install Ansible in your Windows virtual machine).

But to use WSL we need to install it! And to install it we're going to use Vagrant. Lets take a look at our Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

  SHELL

end

If this vagrantfile looks familiar it should! This is the vagrantfile from our previous post where we define our machine configuration and installed Chocolatey.

Now what we want to do is install WSL and to do so we need to add the installation command into our Shell provisioner.

So, copy paste this to the shell terminal in your vagranfile:

Enable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online -NoRestart -WarningAction SilentlyContinue

So, our vagrantfile should look like this for now:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
    Enable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online -NoRestart -WarningAction SilentlyContinue

  SHELL

end

So, we now have WSL installed in our Windows Server vm! This is great and we now have the freedom to use it at will!

Since we installed Chocoaltey and WSL we want to be sure that the machine takes in to account the modifications applied.

For that we will use a provisioner (shell) reload:

  config.vm.provision :reload

We will add this after our shell provisioner just like this:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
    Enable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online -NoRestart -WarningAction SilentlyContinue

  SHELL

  # trigger reload
  config.vm.provision :reload

end

Now that our provisioner is reloaded we can install Kali Linux (Linux distribution base on Debian).

For that we're going to open another termninal and use chocolatey to install it.

Right after installing kali linux we're going to reload our provisioner once again.

This will give us certitude that everything was restarted including the virtual machine itself!

So, lets see what we need to add:

  # execute code after reload
  config.vm.provision "shell", inline: <<-SHELL
    choco install wsl-kalilinux -y
  SHELL

  # trigger reload
  config.vm.provision :reload

And now that everything is fresh and clean lets open another shell terminal and start using WSL!

To start using WSL and see if it works lets add a shell with a simple package update:

wsl sudo apt update

Pretty easy right? So, lets see how we can use it effectively.

To try it out lets install some tools that we're going to need.

So lets install Ansible and unzip package:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
    Enable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online -NoRestart -WarningAction SilentlyContinue

  SHELL

  # trigger reload
  config.vm.provision :reload

  # execute code after reload
  config.vm.provision "shell", inline: <<-SHELL
    wsl sudo apt update
    wsl sudo apt install -y ansible
    wsl sudo apt install -y unzip
  SHELL
end

Why do we need to install Ansible and Unzip might you ask? Well, we'll need to unzip some files so that's why we need Unzip.

For Ansible it requires a little bit more explaination, come with me :)

Ansible​

Ansible is an automation engine, that works with .yml files called playbooks, that automates cloud provisioning, configuration management, application deployment, intra-service orchestration, and many other IT needs.

It uses no agents and no additional custom security infrastructure, so it's easy to deploy - and most importantly, it uses a very simple language (YAML, in the form of Ansible Playbooks) that allow you to describe your automation jobs in a way that approaches plain English.

We also have a hosts (also known as Inventory) file. That's where we're going to add our target machines that we wish to run the playbooks.

Go check the link for a more deep and detailed information about Ansible and what it does

So, to use Ansible we need a working playbook, hosts and a bunch of other stuff! And for that we're going to use wget to donwload a zip file containing all of this (our unzip package will come in handy :D )

Just copy paste this to your provisioner:

    wsl wget https://github.com/j0rdan-m/vagrant_wsl_ansible/archive/master.zip

This will download the zip file.

But we need to unzip it, so:

    wsl unzip master.zip

Thanks to this work we now have working playbooks available to us.

But before we check them out lets configure our hosts file. We will just add the localhost machine into the hosts file with an user, password, connection method and port configuration.

If everything is correct this should work perfectly with your playbooks

    wsl sudo bash -c "echo [self] >> /etc/ansible/hosts"
    wsl sudo bash -c "echo 127.0.0.1 >> /etc/ansible/hosts"
    wsl sudo bash -c "echo [self:vars] >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_port=5985 >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_connection=winrm >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_winrm_transport=basic >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_user=vagrant >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_password=vagrant >> /etc/ansible/hosts"

And, just to be sure that everything is correct, lets ping our vm:

    wsl ansible self -m win_ping

Now that the hosts file is correct we can advance to our playbooks!

We have 3 to be exact! One to install IIS, one to install some tools (Git, VSCode and SumatraPDF) and the last one that creates a service user and gives him the rights to the correct folders.

To use them we need to use ansible-playbook command just like this:

    wsl ansible-playbook vagrant_wsl_ansible-master/tools.yml
    wsl ansible-playbook vagrant_wsl_ansible-master/iis.yml
    wsl ansible-playbook vagrant_wsl_ansible-master/users.yml

This will launch each playbook in the order presented.

So, our playbook should look something like this:

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
    Enable-WindowsOptionalFeature -FeatureName Microsoft-Windows-Subsystem-Linux -Online -NoRestart -WarningAction SilentlyContinue

  SHELL

  # trigger reload
  config.vm.provision :reload

  # execute code after reload
  config.vm.provision "shell", inline: <<-SHELL
    choco install wsl-kalilinux -y
  SHELL

  # trigger reload
  config.vm.provision :reload

  # execute code after reload
  config.vm.provision "shell", inline: <<-SHELL
    wsl sudo apt update
    wsl sudo apt install -y ansible
    wsl sudo apt install -y unzip
    wsl wget https://github.com/j0rdan-m/vagrant_wsl_ansible/archive/master.zip
    wsl unzip master.zip
    wsl sudo bash -c "echo [self] >> /etc/ansible/hosts"
    wsl sudo bash -c "echo 127.0.0.1 >> /etc/ansible/hosts"
    wsl sudo bash -c "echo [self:vars] >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_port=5985 >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_connection=winrm >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_winrm_transport=basic >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_user=vagrant >> /etc/ansible/hosts"
    wsl sudo bash -c "echo ansible_password=vagrant >> /etc/ansible/hosts"
    wsl ansible self -m win_ping
    wsl ansible-playbook vagrant_wsl_ansible-master/tools.yml
    wsl ansible-playbook vagrant_wsl_ansible-master/iis.yml
    wsl ansible-playbook vagrant_wsl_ansible-master/users.yml

  SHELL

end

We now have a fully working Windows Server virtual machine with Ansible and a bunch of other cool stuff in it!

Hope that this was helpfull and make sure to check the other posts ;)

Let's start!

Vagrant​

Now lets see how we can create one to our needs and wants.

So, first things first, the VM. We decided to go with a Windows Server 2019 os and to do so we searched for a Windows Server box on vagrants box websit In the website just tap, into the search box, the type of vm your looking for (could be Linux, Windows, etc). In our case we just have to type "mcree/win2019" and you'll find it. Inside the box page you'll find "Vagrantfile" and "New". Our interest for this post is the "Vagrantfile". As you can see in the box page there's the initial Vagrantfile configuration. You will need this to create (up) your virtual server machine. This is the start of our Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"
end

As you can see, we get the box for our vm and its version.

Now, lets add the name of our vm and the amount of memory (RAM) do we want to give to it:

wvm.vm.provider "virtualbox" do |v|
  v.name = "Windows Server 2019"
  v.memory = "2048"
end

Now that we have our vm name and RAM capacity lets configure the network:

wvm.vm.define "Windows Server 2019" do |web|
  web.vm.hostname = "winserver19"
  web.vm.network "public_network"
end

Here we define the hostname of the vm and the type of network that we wish to give the vm (Public, Private, etc)

Note that there's multiple variants of network configuration, this post will only show you the most basic way to Up your vm;

And the Vagrantfile should look something like this by now:

Vagrant.configure("2") do |config|
  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  wvm.vm.define "Windows Server 2019" do |web|
    web.vm.hostname = "winserver19"
    web.vm.network "public_network"
  end
end

This is a very simple and easy (just how we like it) to configurate Vagrantfile.

But we want to have some tools installed on the vm when we Up our virtual machine. To do so we're going to use a terminal (shell).

So, we need to add to the Vagrantfile the terminal:

config.vm.provision "shell", inline: <<-SHELL

SHELL

This is the terminal that is going allow you to give commands to add, remove, move and a bunch of other things to the vm;

So, we're going to install Chocolatey (see below explaination of what is chocolatey and how to install it) and, using Chocolatey, we're going to install Git, VSCode and Hugo;

Note that SHELL at the end of the terminal replaces the end in the other configurations seen previously.

Chocolatey​

Chocolatey is a module for windows to install packages (tools) on to the machine. For example, "choco install tool" is the equivalent to "apt install tool" on Ubuntu. So to install it you need to copy paste this command to your vagrantfile shell provisioner:

config.vm.provision "shell", inline: <<-SHELL

  Set-ExecutionPolicy Bypass -Scope Process -orce; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

SHELL

This command will install chocolatey and allow you to use "choco install" to install other tools into your windows server such as Git or VSCode.

Tools​

Now you need to install the tools that you need and to do so you'll use Chocolatey! So, add to your vagranfile shell the following commands:

choco install git -y
choco install vscode -y
choco install hugo -y

These commands will install the respective tools, but you can install the tools that you need. The only thing that you need to is choco install "tool that you want" :) Note, that the -y is to answer Yes to the questions asked by the installation process;

So, our Vagrantfile looks like it's complete! So lets see how it looks like with all put togheter:

The complete Vagrantfile​

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "mcree/win2019"
  config.vm.box_version = "1.0.1584095692"

  config.vm.provider "virtualbox" do |v|
    v.name = "Windows Server 2019"
    v.memory = "2048"
  end

  wvm.vm.define "Windows Server 2019" do |web|
    web.vm.hostname = "winserver19"
    web.vm.network "public_network"
  end

  config.vm.provision "shell", inline: <<-SHELL

    Set-ExecutionPolicy Bypass -Scope Process -orce; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))
    choco install git -y
    choco install vscode -y
    choco install hugo -y

  SHELL

end

Here is how I write technicals articles, to make it readable, and usefull for the future myself who want to remember how to use that technical stuff I wrote an article about several month ago.

What you're reading is the introduction. I start by intro, because my theme take that text as summary in the first page.

Here is my post.md file beginning :

*my archetype*
--

Aujourd'hui, en français, je souhaite aborder le sujet des archétypes du moteur de génération de site Hugo. Ce moteur très performant est d'ailleurs utilisé pour générer ces pages.

<!--truncate-->

Some theme understand the "more balise" so my intro ends with it.

I can end my intro after the <!--truncate--> if I think it's too long, or something else.

Titles​

I continue the post by using title. I think Title is important, because it allow us understand the structure of the article, and allow "power users" to go directly to the part they except to find informations.

on my previous article, about archetypes, my titles was :

# archetypes/Default.md

(...)

# archetypes/mon_mien.md

(...)

I could have used a more complex structure by using second or third level of titles

# First level

## Second level

### Third level

That code will be displayed like this on the blog :

First level​

blablabla

Second level​

blablabla explained

Third level​

blablabla more specified

It's important to put Title on your tutos. Sometimes, readers would read more than one tuto at the same time, and it's easier to go to next part when title organized the page.

Code display​

There is two kinds of way to put code on markdown :

inline code​

This is when you use ``` 'my code is cool' ``` in the same line than the rest of the text

single line code isolated​

This is when you use :

```
my code is cool
```

The code is isolated from the rest of the paragraph

My advise​

Always use the second one. For a simple reason : People do use copy/paste. And it is so easier to copy paste a single line.

Next tips​

Bullets​

• Do not
• use
• bullet
• everywhere

Do it when it's usefull. There are two cases :

• list of stuff
• list of stuff

Use quote for quoting​

Use quote for quote. I know it sounds weird, but you could want to use the nice quote format for something else. Don't.

Quote style is for quote - Dr. CssProvider

What do you need?​

We will use 2 tools to make the deployment of the Ubuntu vm very fast!

These tools are Vagrant and Virtual Box.

Installation​

By Download​

Note that you have to choose the OS where you wish to install the tool (Linux, Windows, etc...)

• Vagrant -> download Vagrant

• Virtual Box -> download Virtualbox

By using package management​

Windows - Chocolatey​

To start you need to install Chocolatey. For that I have a post explaining how to it correctly here -> Now that you have installed Chocolatey lets use it. Lets start with VirtualBox, so for this use the following command:

choco install virtualbox

And now Vagrant:

choco install vagrant

Linux - apt​

This is the same concept as choco install but for Linux of course. So, for Linux, we will use apt install. For VirtualBox:

sudo apt install virtualbox

For Vagrant:

sudo apt install vagrant

Deployment:​

So, first we need the Vagrant box (don't forget to see the Vagrant post on the page to learn a bit more about Vagrant boxes). For this example we will use Ubuntu 18.04 LTS

Now, in your local machine, access your terminal, create a folder for your Vagrant box and, inside your new folder, type:

vagrant init ubuntu/bionic64

Doing this will add the box to your local Vagrant. And now, let's create our Ubuntu virtual machine! So tap in your terminal:

vagrant up

And there it is! Your first fresh and clean Ubuntu vm!

The archetypes are the elements that generate the Hugo page headers, when created with the command hugo new my_file.md.

archetypes/Default.md​

The default.md in the archetype applies to all the "new hugo" you will create. This default.md is customizable, as seen in the previous article, Managing content in a Hugo site, but it can also be multiplied.

archetypes/mon_mien.md​

Let's imagine the case of an ESN site (at random ;) ), in which we will find a home page, a certain number of 'Products' pages, 'Offers' pages and a 'blog' page.

you just have to create, in the folder archetypes, three files :

• product.md
• offer.md
• post.md

these three files will contain the appropriate archetypes according to the type of page.

It is very simple to apply an archetype to a page: the archetype must have the same name as the directory hosting the page type!

For example, to create a product page, an offer page and a blog post, we will use these three commands:

# Nouvelle page produit
hugo new produit/eaviz.md

# Nouvelle offre Marte
hugo new offre/expert_ansible.md

# Nouvel article de blog
hugo new post/gestion_archetype.md

Managing themes​

Like the config.toml of the exampleSite section of a theme, I strongly advise you to start from the archetype(s) proposed by a theme. This will allow you to know the right working directories to see your pages appear in the places provided by the theme.

The purpose of this post is to clarify the way to proceed to facilitate the creation of post.

Disclaimer: the official tutorial is **very bad** in the case of a site that we want to deploy under gitlab Pages !

Page management​

In the context of a site in blog mode, it is relatively simple.

The command hugo new <repertoire>/<nom d'article>.md allows you to add articles in MD format in the "directory" folder. Usually, we use "post" for a blog.

Page properties​

The properties of a page are managed in the header of the created pages. They can be found in the following form:

---
title: "mon article"
date: AAAA/MM/DD/THH:MM:SS
draft: true

This is the standard generated by Hugo. There are two things to note:

1. In a deployment in gitlab, only "draft: false" pages are displayed. The "draft: true" pages are ignored when building the site. It is then possible to build a site locally (with the -D option for draft) and test some pages while taking advantage of gitlab hosting.
2. The basic version can be completed with other information about the created page:

• subtitle: to add a subtitle
• tags: to add tags to an article
• categories: to categorize the articles

In short, nothing crazy, but it is useful. So, the header of the article you are reading is :

---
title: "Gérer du contenu dans un site Hugo"
date: 2020-04-14T09:39:30Z
draft: false
subtitle: "Comment gérer du contenu dans un site statique généré par Hugo"
tags:
- français
- hugo-tips
categories:
- hugo
---

Image management​

To manage the images displayed in an article, here is the solution I propose, and which has the advantage of working with hugo locally, but also with a gitlab deployment:

1. Create a sub-folder "images" in the "content" directory
2. Put the images you want to appear in your article
3. add ![texte alternatif](../../images/mon_image.jpg) in your article, where you want the image to appear.

Manage content related to themes (background photos, avatars, etc.)​

In these cases, the management of local images can be complicated to manage if you want the operation to be identical whether you use the hugo engine locally or in the Gitlab Pages version.

That's why I propose to manage it in the following way:

Create a directory called "static" at the root of your site. Put the images you want to use directly in this directory, without putting them in a subdirectory. They will then be usable in your config.toml file by simply giving their name.

But you should start carefully, because the quickstart isn't compliant with a gitlab Pages deployment.

How to quickstart with hugo​

This is how I think you should start with Hugo :

step 1 - Theme selection​

First, choose carefully the thème you want to use. It's important because the way you'll configure your website could be (very) specific to your theme.

To choose wisely, you juste have to go on themes.gohugo.io and look at demo. All demos include the markdown syntax restitution, which could allow you to be sure that the theme answer your desire !

step 2 - Website name​

Second, choose wisely the website name. Because it has to be the folder name. when you'll deploy your website on gitlab Pages, you would have the following website URL : http://username.gitlab.io/foldername/

If you're creating a blog, "blog" would be a good name. If you're on website to propose a product, "productName" would be wise.

step 3 - website creation​

Easiest part of the tutorial. Do nothing else typing the following command :

hugo new site <foldername>

Now, you've a new folder called foldername with some stuff in it. Before doing anything, follow the next step. DO NOT ENTER IN THE NEW FOLDER

step 4 - theme downloading​

Go on your chosen theme repository and DO NOT CLONE the git repository. Get the zip file, and unzip it on foldername/themes/themeName.

Be carefull, the content of the theme has to be on themeName, not on themeName/hugo-theme-name-master.

step 5 - Use exampleSite as template​

Copy the themeName/exampleSite/config.toml directly on your foldername, replacing the standard one.

On the config.toml file, modify the theme selection line by

theme = "<themeName>"

Since you want to use hugo with gitlab pages, you should also modify the baseURL on config.toml :

baseurl = "https://<username>.gitlab.io/<foldername>"

Gitlab Pages deployment​

Warning​

DO NOT GIT INIT ANYTHING ! You'll create a gitlab project and you'll init

step 6 - Create gitlab project​

On gitlab, create a new projet, called by the same name as your folder name. Do not initialize it with a readme or something else.

step 7 - Create your CI file​

Go on your folder name, and create a file called .gitlab-ci.yml

Edit the file with the following code :

image: monachus/hugo

variables:
  GIT_SUBMODULE_STRATEGY: recursive

pages:
  script:
  - hugo
  artifacts:
    paths:
    - public
  only:
  - master

step 8 - Push your website​

First, init the repo :

git init

Then, add /public directory to our .gitignore file

echo "/public" >> .gitignore

Finally, commit and push code to master branch

git add .
git commit -m "Initial commit"
git remote add origin https://gitlab.com/YourUsername/your-hugo-site.git
git push -u origin master

step 9 - See & Wait​

Go on the "CI/CD pipeline" tab of your gitlab repository

Check the build, and wait for passed. You're in ! Your website is published on username.gitlab.io/foldername

It's only a support to formalize the research activities of two bad it boys.

About the website:

Here are some information about the technical stack of the website.

The Stack​

To provide this website, we're running the JAMstack: Javascript, Apis, Mark-up languages.

More precisely, our stack is composed by:

We are writing articles in arkdown, using Cloudinary to store and share images. The blog is build with hugo, tested and deployed on Netlify by Gitlab CI/CD.

Here is our workflow:

{{}}