Archives par mot-clé : user-data

Trucs et astuces pour systemd

Monter un répertoire nfs avec systemd

Il vous faut créer un fichier .mount normalisé.
Le nom du fichier, par convention, doit correspondre au path du point de montage, par exemple à /mnt/nfs correspond le fichier mnt-nfs.mount
Cette unit devant être gérer par le système, il doit se trouver dans /etc/systemd/system .

vi /etc/systemd/system/mnt-nfs.mount
        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target

testez

systemctl daemon-reload
systemctl start mnt-nfs.mount
systemctl status mnt-nfs.mount

Avoir accès aux variables systemd dans une unit mount

Malheureusement systemd ne donne pas accès à ses variables (par exemple %H) dans la requête nfs créée.
Si vous avez besoins par exemple d’avoir un partage propre à chaque machine, pour contourner cette limitation vous pouvez passer par des variables d’environnement comme ceci:

        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/${HOST}
        Environment="HOST=%H"
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target

Monter automatiquement avec Systemd

automount suit la même convention que mount.
Il vous faut créer un fichier .automount normalisé.
Le nom du fichier, par convention, doit correspondre au path du point de montage, par exemple à /mnt/nfs correspond le fichier mnt-nfs.automount
Cette unit devant être gérer par le système, il doit se trouver dans /etc/systemd/system .

        [Unit]
        Description = nfs auto mount core to host
        
        [Automount]
        Where = /mnt/nfs
        
        [Install]
        WantedBy=multi-user.target

Ajouter une dépendance à automount pour Docker

Votre unit .automount n’ayant pas de dépendant, il ne s’executera pas au démarrage de vote système.
Si par exemple, vous avez besoins de ce point de montage pour docker, vous pouvez modifier votre unit docker.
Dans le cas d’un système CoreOS, modifier /etc/systemd/system/early-docker.service comme suit.
Regarder le paramètre Requires
Tips 2 : Changer le home de Docker sur support nfs : modifier ExecStart en ajoutant –graph et –storage-driver.

        [Unit]
        Description=Early Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=early-docker.socket
        Requires=early-docker.socket mnt-nfs.automount  mnt-nfs.mount
        
        [Service]
        Environment=TMPDIR=/var/tmp
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/early
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --bridge=none --iptables=false --ip-masq=false --graph=/mnt/nfs/early --pidfile=/var/run/early-docker.pid --storage-driver=overlay $DOCKER_OPTS
        
        [Install]
        WantedBy=early-docker.target

Mountage Automatique avec Systemd sur CoreOS dans user-data

Et l’on prend les points ci-dessus pour les mettre dans un user-data coreOS…

  - name: mnt-nfs.mount
    content: |
        [Unit]
        Description = nfs mount core to host
        
        [Mount]
        What = votreserveurnfs:/votrepartage/${HOST}
        Environment="HOST=%H"
        Where = /mnt/nfs
        Type = nfs
        Options = vers=3,nolock,udp
        
        [Install]
        WantedBy = multi-user.target
  - name: mnt-nfs.automount
    content: |
        [Unit]
        Description = nfs auto mount core to host
        
        [Automount]
        Where = /mnt/nfs
        
        [Install]
        WantedBy=multi-user.target
    
  - name: docker.service
    content: |
        [Unit]
        Description=Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=docker.socket early-docker.target network.target
        Requires=docker.socket early-docker.target

        [Service]
        EnvironmentFile=-/run/flannel_docker_opts.env
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/docker
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// $DOCKER_OPTS $DOCKER_OPT_BIP $DOCKER_OPT_MTU $DOCKER_OPT_IPMASQ --graph=/mnt/nfs/docker --storage-driver=overlay  

        [Install]
        WantedBy=multi-user.target
        
    command: restart
  - name: early-docker.service
    content: |
        [Unit]
        Description=Early Docker Application Container Engine
        Documentation=http://docs.docker.com
        After=early-docker.socket
        Requires=early-docker.socket mnt-nfs.automount  mnt-nfs.mount
        
        [Service]
        Environment=TMPDIR=/var/tmp
        MountFlags=slave
        LimitNOFILE=1048576
        LimitNPROC=1048576
        ExecStartPre=-/usr/bin/mkdir -p /mnt/nfs/early
        ExecStart=/usr/lib/coreos/dockerd daemon --host=fd:// --bridge=none --iptables=false --ip-masq=false --graph=/mnt/nfs/early --pidfile=/var/run/early-docker.pid --storage-driver=overlay $DOCKER_OPTS
        
        [Install]
        WantedBy=early-docker.target

pour que ces units s’éxecutent au démarrage vous pouvez jouer avec leur flags
runtime: true
enable: true

voir la documentation de coreOs sur user-data unit

Docker sur CoreOS par Vagrant

Pourquoi ce tuto ?

  • des billes sur coreOs
  • des billes sur Vagrant
  • de quoi se faire un cloud 3 instances CoreOs avec etcd2 avec partage samba clef en main sur un hôte Microsoft Windows

Introduction

L’utilisation de Docker est fortement influencer par sa plateforme hôte, il peut tourner sur une simple busybox, sur debian / ubuntu, manipuler par Kubernetes ou complétement réécrit comme sur coreos.

J’ai choisi de vous présenter CoreOs pour sa simplicité et son fort potentiel avec fleet, etcd et cette notion cloud “new age”…

Environnement de test

J’ai pour contrainte de faire mes tests sur un Windows Server, donc pour se simplifier la vie, il nous faut un provider de machine virtuelle simple et efficace comme Virtualbox et un gestionnaire comme Vagrant.

Donc prérequis:

  • VirtualBox 5
  • Vagrant 1.8
  • Git
  • des droits d’admin sur votre hôte windows (ou encore mieux linux)

Optionnel mais conseillé si vous êtes sous windows:

  • Chocolatey
  • Console Emulator : choco install conemu
  • Babun : http://babun.github.io/

Pratique

Clone it

récupérer mon fork de CoreOS-vagrant, en plus de l’original, vous aurez:

  • une configuration samba autogénérée sur le répertoire courant
  • la possibilité de configurer un proxy pour votre cloud
  • quelques trucs et astuces préconfigurés pour CoreOS
git clone https://github.com/heralight/coreos-vagrant.git

Initialiser la configuration

P.S.: vagrant à besoins d’internet pour récupérer les images des vms demandées, à minima lors de la première exécution.

copier les ‘*.sample’ vers ‘‘ (.x.sample étant des versions de configuration alternative suivant vos goûts et couleurs)

  • config.rb
    configuration de l’instanciation vagrant coreos, la v2 instancie 3 vm et fonctionne sans internet après le premier lancement

  • sync-folders.yml
    vous permet de paramétrer vos partages entre votre hôte et vos instances, par samba (smb, smb2, rsync, nfs, vboxsf). le sample va créer un utilisateur windows ‘vagrant’, créer un partage pour le répertoire courant assigné à cet utilisateur.

  • user-data
    configuration de l’instance coreos proprement dite. le sample fonctionne sans internet, active etcd2, fleet, flannel et quelques autres tips, le tout pour 3 instances.

Utilisation

Démarrage

vagrant up

La première fois, cette commande va récupérer et provisionner des instances coreos, les paramétrer et les lancer.
Dans le cas où vous utiliseriez samba, l’utilisateur vagrant sera créé, ainsi que le partage.
Des consoles vous demandent d’appliquer des changements au système hôte, c’est normal, vu que l’on crée des utilisateurs, applique des droits et crée des partages.

Cette partie asynchrone peut ne pas s’exécuter dans le bon ordre la première fois, si cela échoue => vagrant halt puis vagrant up

Arrêt

vagrant halt

Connexion ssh

  • si une seule instance
vagrant ssh
  • si plusieurs instances, par exemple la une ‘core-01’
vagrant ssh core-01

Redéploiement du user-data

si vous modifier votre user-data et que vous voulez impacter vos instances actuelles vous pouvez

Méthode 1

reprovisionner vos instances, ce qui aura pour effet de recopier votre user-data :

vagrant provision

puis de forcer pour l’application de ces changements sur chaque instance en executant en ssh root:

coreos-cloudinit --from-file  /var/lib/coreos-vagrant/vagrantfile-user-data
Méthode 2

ou plus simplement :

vagrant  --reapply-user-data up

qui automatise la méthode 1

Trucs et actuces

Ajouter ou modifier les lignes suivantes dans votre user-data.
Si l’instance existe, pensez à réappliquer cette configuration (voir plus haut).

Changer toolbox docker image

Vous préférez un gestionnaire ubuntu pour coreos, pas de souci!

write_files:
- path: "/home/core/.toolboxrc"
  owner: core
  content: |-
    TOOLBOX_DOCKER_IMAGE=ubuntu
    TOOLBOX_DOCKER_TAG=14.04

ajouter un proxy à votre configuration Docker

sous units
  - name: docker.service
    drop-ins:
    - name: 20-http-proxy.conf
      content: |
        [Service]
        Environment="HTTP_PROXY=http://yourproxy:port" "HTTPS_PROXY=http://yourproxy:port" "http-proxy=http://yourproxy:port" "https-proxy=http://yourproxy:port"    "NO_PROXY=localhost,127.0.0.0/8,172.17.0.0/16,.sock,yourproxy,/var/run/docker.sock"
    command: restart

démarrer automatiquement le daemon fleet

sous coreos
  fleet:
    etcd-servers: http://$private_ipv4:2379
    public-ip: "$private_ipv4"
sous units
  - name: fleet.service
    command: start

Add simple flannel

sous coreos
  flannel:
    interface: "$public_ipv4"
sous units
  - name: flanneld.service
    drop-ins:
    - name: 50-network-config.conf
      content: |
        [Service]
        ExecStartPre=/usr/bin/etcdctl set /coreos.com/network/config '{ "Network": "10.1.0.0/16" }'
    command: start
    

configuration etcd pour 3 instances sans discovery internet

Cette configuration etcd fonctionne pour 3 instances sans discovery internet (sans dépendances vers discovery_url), les ips fixes sont données à titre indicatif.
Ceci vous montre indirectement comment vous passer du discovery de “https://discovery.etcd.io”
keyword : howto disable discovery etcd.

dans config.rb

commentez ‘token = open($new_discovery_url).read’

sous units
  - name: etcd.service
    command: start
    content: |
      Description=etcd 2.0
      After=docker.service
      Conflicts=etcd.service

      [Service]
      User=etcd
      Type=notify
      EnvironmentFile=/etc/environment
      TimeoutStartSec=0
      SyslogIdentifier=writer_process
      Environment=ETCD_DATA_DIR=/var/lib/etcd2
      Environment=ETCD_NAME=%m
      ExecStart=/bin/bash -c "/usr/bin/etcd2 \
        -name %H \
        -listen-client-urls http://0.0.0.0:2379 \
        -advertise-client-urls http://$COREOS_PRIVATE_IPV4:2379 \
        -listen-peer-urls http://0.0.0.0:2380 \
        -initial-advertise-peer-urls http://$COREOS_PRIVATE_IPV4:2380 \
        -initial-cluster core-01=http://172.17.8.101:2380,core-02=http://172.17.8.102:2380,core-03=http://172.17.8.103:2380\
        -initial-cluster-state new"
      Restart=always
      RestartSec=10s
      LimitNOFILE=40000
      TimeoutStartSec=0



      [Install]
      WantedBy=multi-user.target

      [X-Fleet]
      Conflicts=etcd*

Pour tester votre configuration etcd connectez-vous en ssh sur 2 instances, déjà vous devriez tester l’état du service etcd:

 systemctl status etcd
status des noeuds etcd
etcdctl cluster-health
écoute de tous les sujets sur un noeud
etcdctl watch /message --forever 
broadcast d’un message à partir d’un autre
etcdctl set /message "Salut CoreOS, jolie com!" 

D’autre exemple etcd sur
Etcd Read Write ref

Have fun !