25 mai 2016

[DevOps] vers un partenariat Jenkins/Microsoft Azure ?

Jenkins noue un partenariat avec Microsoft afin de migrer son infrastructure sur Azure

L'outil d'intégration entend mieux satisfaire ses utilisateurs

Le 23 mai 2016, par Olivier Famien, Chroniqueur Actualités

Source : developpez.net
 
Microsoft vient d’annoncer un partenariat avec l’équipe de développement de Jenkins afin d’héberger l’infrastructure de ce projet sur sa plateforme. Jenkins est un outil open source d’intégration continue. Il offre des centaines de plug-ins afin de construire, déployer et automatiser différents types de projets.

Depuis plusieurs années, explique la firme de Redmond, le projet Jenkins dont l’infrastructure est basée sur Linux s’est appuyé sur plusieurs plateformes pour fournir aux individus et aux entreprises les outils dont nous disposons actuellement. Certains de ces plateformes et serveurs ont été fournis « par les membres de la communauté, d’autres donnés par la générosité par des fondations et des établissements d’enseignement ».

« Comme le projet Jenkins et la demande pour Jenkins ont augmenté, le projet a besoin d’une plateforme Linux plus fiable, plus sure et plus agile sur laquelle construire les prochaines générations de leur réseau de distribution de contenu et des outils Java », souligne Microsoft.

Aussi, pour aider les infrastructures Jenkins à atteindre cet objectif, un partenariat a été conclu entre ces deux acteurs afin de migrer l’infrastructure Jenkins sur la plateforme Azure. De manière détaillée, Microsoft s’engage à travers ce partenariat à fournir « les ressources de calcul et l’expertise technique pour construire un développement moderne et robuste de l’infrastructure de livraison sur Linux et Java dans le cloud Azure.

De même, Microsoft ajoute que « Azure hébergera également le site Web de Jenkins et la version Jenkins qui gère le site. Jenkins offrira Jenkins 2 et les anciennes versions de Jenkins aux équipes dans le monde entier en utilisant l’infrastructure sécurisée et évolutive d’Azure ».

De son côté, Jenkins accueille avec joie ce partenariat et explique les avantages de cette alliance en soutenant ouvertement qu’il « arrive à un moment important, après le lancement récent de Jenkins 2.0, les utilisateurs Jenkins adoptent graduellement le plug-in Pipeline comme code et beaucoup d’autres plug-ins à un rythme croissant, ce qui surélève l’importance de l’infrastructure Jenkins pour la réussite globale du projet ».

Il soutient également que « cette croissance forte et continue a entrainé de nouvelles exigences pour la conception et à la mise en œuvre de notre infrastructure, ce qui nécessite la prochaine étape de son évolution ». Et de conclure que « ce partenariat nous aide à grandir avec le reste du projet en unifiant notre infrastructure existante sous une plateforme complète, moderne et évolutive ».

Manifestement, les deux structures semblent tirer de gros avantages dans cette collaboration. Jenkins qui pourra bénéficier des outils modernes et robustes de la plateforme Azure afin de maintenir la disponibilité de ses outils et Microsoft qui en accueillant ces infrastructures attirera davantage de personnes vers sa plateforme.

Source : Blog Azure, Blog Jenkins

19 mai 2016

[ANSIBLE] interagir avec des webservices

Utilisation du module uri pour interagir avec des webservices HTTP ou HTTPS

Voici plusieurs exemples de l'utilisation du module uri:
    # Check that you can connect (GET) to a page and it returns a status 200
    - uri: url=http://www.example.com

    # Check that a page returns a status 200 and fail if the word AWESOME is not
    # in the page contents.
    - action: uri url=http://www.example.com return_content=yes
      register: webpage

    - action: fail
      when: "'AWESOME' not in webpage.content"


    # Create a JIRA issue
    - uri:
        url: https://your.jira.example.com/rest/api/2/issue/
        method: POST
        user: your_username
        password: your_pass
        body: "{{ lookup('file','issue.json') }}"
        force_basic_auth: yes
        status_code: 201
        body_format: json

    # Login to a form based webpage, then use the returned cookie to
    # access the app in later tasks

    - uri:
        url: https://your.form.based.auth.example.com/index.php
        method: POST
        body: "name=your_username&password=your_password&enter=Sign%20in"
        status_code: 302
        HEADER_Content-Type: "application/x-www-form-urlencoded"
      register: login

    - uri:
        url: https://your.form.based.auth.example.com/dashboard.php
        method: GET
        return_content: yes
        HEADER_Cookie: "{{login.set_cookie}}"

    # Queue build of a project in Jenkins:
    - uri:
        url: "http://{{ jenkins.host }}/job/{{ jenkins.job }}/build?token={{ jenkins.token }}"
        method: GET
        user: "{{ jenkins.user }}"
        password: "{{ jenkins.password }}"
        force_basic_auth: yes
        status_code: 201

Mon besoin initial:

pouvoir reproduire cette commande curl:
curl -XPUT http://localhost:6059/books/test.json -H "Accept: application/json" -H "Content-Type: text/plain" -d '
user=astunix
home=/home/astunix'
en format Ansible:
- name: Create catalog on ElasticSearch
  uri:
    url: "http://localhost:6059/catalogs/{{ book_name }}.json"
    method: PUT
    HEADER_Content-Type: "application/json"
    HEADER_Content-Type: "text/plain"
    body: "user=astunix\n
home=/home/astunix"
  sudo: true
Bien entendu, method peut comporter d'autres options que PUT:
  • GET
  • POST
  • PUT
  • HEAD
  • DELETE
  • OPTIONS
  • PATCH
  • TRACE
  • CONNECT
  • REFRESH

Plus d'information sur le site officiel de Ansible : http://docs.ansible.com/ansible/uri_module.html

[ANSIBLE] ignore_errors

Ou comment ignorer une instruction en erreur dans Ansible


Il arrive que des commandes retourne des erreurs...
Dans certains cas, on peut dire que ce ne soit pas une vraie erreur mais plutôt un WARNING déguisé en ERROR :-)

Dans ce cas là, j'utilise:
ignore_errors: yes
ou
ignore_errors: true
qui fera apparaitre un petit :
...ignoring
juste après le retour d'erreur et passera à l'instruction suivante.

Bien entendu cette fonction est à utiliser avec parcimonie, et il faudra corriger ce fameux code retour en erreur.



Différences majeures entre Red Hat 6, 7, 8 et 9

Quelles sont les différences majeures entre RHEL 6, 7, 8 et 9 ? Système de fichiers RHEL 6: Par défaut : ext4. Autres : ext2, ext3 supportés...