Comprendre les directives du fichier nginx.conf

Nous allons maintenant bien comprendre le fichier nginx.conf. Si vous ne vous rappelez pas où se trouve ce fichier, reportez-vous à la leçon correspondante.

Ouvrir nginx.cong

Je vous invite à vous connecter à votre serveur et à ouvrir nginx.conf.

nano nginx.conf

De nombreuses choses sont affichées.

user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers on;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}


#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

Cela fait beaucoup de choses à assimiler 😳.

Pour bien bien comprendre les directives, je vous propose de tout supprimer et de les réécrire petit à petit tout en expliquant leurs fonctions.

Directive : user

Nous allons commencer par la directive « user » de notre fichier de configuration nginx.conf.

Elle spécifie le nom de l’utilisateur système sous lequel est exécuté le processus nginx.

Par défaut, c’est « www.data ». On peut laisser l’« user » par défaut.

user www.data;

Directive : worker_processes

La directive « worker_processes » permet d’indiquer à Nginx le nombre de processus que le serveur doit créer pour traiter les requête client.

Le mieux est d’écrire la valeur « auto ». Ainsi, Nginx déterminera de lui-même le nombre optimal en fonction du nombre de cœurs de CPU de votre serveur.

user www.data;
worker_processes auto;

Directive : pid

La directive « pid » contient le chemin qui pointe vers un fichier (.pid) qui contient le PID ou l’ID de processus de Nginx.

Par défaut, Nginx l’enregistre dans /run/nginx.pid.

Nous pouvons garder cette valeur également dans notre fichier nginx.conf.

user www.data;
worker_processes auto;
pid /run/nginx.pid;

Vérifier nginx.pid

Est-ce que vous voulez vérifier que ce fichier existe bien ?

Ouvrez un autre onglet du terminal de votre serveur et tapez les commandes suivantes.

cd /run

ls

agetty.reload  dbus     motd.dynamic  rpcbind          sshd.pid  utmp
console-setup  exim4    mount         screen           sudo      xinetd.pid
credentials    initctl  named         sendsigs.omit.d  systemd
crond.pid      lock     network       shm              udev
crond.reboot   log      nginx.pid     sshd             user

Nous voyons bien notre fichier nginx.pid 😄.

Section : events

La section event est utilisée pour définir les paramètres qui ont un rapport avec les connexions et les évènements réseau gérés par Nginx.

Nous allons analyser deux directives de cette section.

Connexions

Les connexions de réseau sont des liens établis entre deux ordinateurs pour qu’ils puissent communiquer ensemble. Dans le cas de Nginx, il gèrera la communication entre le serveur et l’ordinateur de l’utilisateur.

Évènements

Les évènements de réseau sont des évènements sur les connexions.

Par exemple :

• Requête HTTP reçue
• Requête HTTP envoyée
• Client qui établit une connexion
• etc...

Créer une section

Pour créer une section, il faut utiliser un bloc d’accolades.

user www.data;
worker_processes auto;
pid /run/nginx.pid;

events {



}

Directive : worker_connections (events)

L’information émanant de « worker_connections » indique le nombre de connexions que le serveur peut traiter en même temps.

Quelle indiquée ?

Tel est la question. Cela dépend de la quantité de ressources de votre serveur.

Une valeur trop haute risque de surcharger votre serveur et ainsi dégrader les performances. Si la valeur est trop basse, certaines connexions pourront être perdues.

En général, 1024 est un bon compromis et c’est ce que nous allons indiquer comme valeur.

user www.data;
worker_processes auto;
pid /run/nginx.pid;

events {

 worker_connections 1024;

}

Directive : multi_accept (events)

Lorsque la directive « multi_accept » est activée, le serveur accepte plusieurs connexions en même temps. Lorsqu’elle est désactivée, le serveur n’accepte qu’une connexion à la fois.

Par défaut, Nginx désactive cette directive et nous allons suivre cet exemple. Pour cela, nous n’allons pas l’insérer dans notre fichier de configuration.

La suite de la configuration dans la prochaine leçon

Nous avons déjà abordé beaucoup de points. La suite de la configuration dans la prochaine leçon.