Menggunakan Ansible untuk berinteraksi dengan titik akhir web

Saya selalu mencari hal-hal cerdas untuk dilakukan dengan Ansible. Dengan begitu banyak alat dan layanan yang memanfaatkan Antarmuka Pemrograman Aplikasi (API) berbasis HTTP, jelas bahwa berinteraksi dengan layanan berbasis API dari Ansible secara terprogram adalah kemampuan yang berharga. Ini mungkin terdengar seperti fitur lanjutan, tetapi artikel ini membawa Anda melalui kasus penggunaan yang menunjukkan bagaimana lingkungan yang sederhana pun dapat memperoleh manfaat dari kekuatan dan kesederhanaan modul URI Ansible.

Berinteraksi dengan titik akhir sederhana

Pertama, saya akan memandu Anda melalui buku pedoman yang memanfaatkan kemampuan HTTP Ansible untuk membuat keputusan cerdas selama peningkatan server web. Buku pedoman di bawah ini:

1. Menjalankan skrip pemeliharaan.
2. Memeriksa untuk memastikan bahwa titik akhir API pemeriksaan kesehatan mengembalikan HTTP 503 Layanan Sementara Tidak Tersedia pesan.
3. Menjalankan skrip untuk meningkatkan versi aplikasi.
4. Menjalankan skrip pasca-pemeliharaan untuk memberi tahu server web agar mulai merespons secara normal lagi.
5. Memeriksa ulang health check API untuk memastikan bahwa responsnya dengan 200 OK .

Ini buku pedomannya:

---

- hosts: all
  tasks:
    - name: Run maintenance start script
      command:
        cmd: /usr/local/sbin/start_maintenance.sh

    - name: Confirm that 503 Unavailable response is returned
      uri:
        url: "http://{{ ansible_host }}/api/v1/healthcheck"
        status_code: 503

    - name: Update application
      command:
        cmd: /usr/local/sbin/update_app.sh

    - name: Run maintenance end script
      command:
        cmd: /usr/local/sbin/end_maintenance.sh

    - name: Confirm that 200 OK response is returned
      uri:
        url: "http://{{ ansible_host }}/api/v1/healthcheck"
        status_code: 200

Saya menggunakan modul URI Ansible untuk menjangkau /api/v1/healthcheck di server. Panggilan URI pertama mengharapkan HTTP 503 kode status yang akan dikembalikan karena server harus dalam mode pemeliharaan dan tidak melayani permintaan. Setelah peningkatan, panggilan URI mengharapkan HTTP 200 kode status, yang menunjukkan bahwa server web sudah sehat kembali.

Pendekatan sederhana ini meningkatkan keamanan buku pedoman saya. Jika server gagal masuk ke mode pemeliharaan, Ansible tidak akan melakukan patch apa pun:

fsh$ ansible-playbook -i inventory.ini playbook-healthcheck.yml

PLAY [all] ***********************************************************************************

TASK [Gathering Facts] ***********************************************************************
ok: [nyc1-apiserver-1.example.com]

TASK [Run maintenance start script] **********************************************************
changed: [nyc1-apiserver-1.example.com]

TASK [Confirm that 503 Unavailable response is returned] *************************************
fatal: [nyc1-apiserver-1.example.com]: FAILED! => changed=false 
  connection: close
  content: ''
  content_length: '0'
  content_type: application/octet-stream
  cookies: {}
  cookies_string: ''
  date: Fri, 11 Sep 2020 18:35:08 GMT
  elapsed: 0
  msg: 'Status code was 200 and not [503]: OK (0 bytes)'
  redirected: false
  server: nginx
  status: 200
  url: http://nyc1-apiserver-1.example.com/api/v1/healthcheck

PLAY RECAP ***********************************************************************************
nyc1-apiserver-1.example.com : ok=2    changed=1    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0  

Jika server gagal untuk kembali dengan benar setelah ditambal, maka Ansible gagal dengan kesalahan:

fsh$ ansible-playbook -i inventory.ini playbook-healthcheck.yml

PLAY [all] ***********************************************************************************

TASK [Gathering Facts] ***********************************************************************
ok: [nyc1-apiserver-1.example.com]

TASK [Run maintenance start script] **********************************************************
changed: [nyc1-apiserver-1.example.com]

TASK [Confirm that 503 Unavailable response is returned] *************************************
ok: [nyc1-apiserver-1.example.com]

TASK [Update application] ********************************************************************
changed: [nyc1-apiserver-1.example.com]

TASK [Run maintenance end script] ************************************************************
changed: [nyc1-apiserver-1.example.com]

TASK [Confirm that 200 OK response is returned] **********************************************
fatal: [nyc1-apiserver-1.example.com]: FAILED! => changed=false 
  connection: close
  content: |-
    <html>
    <head><title>503 Service Temporarily Unavailable</title></head>
    <body>
    <center><h1>503 Service Temporarily Unavailable</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>
  content_length: '190'
  content_type: text/html; charset=utf-8
  date: Fri, 11 Sep 2020 18:55:01 GMT
  elapsed: 0
  msg: 'Status code was 503 and not [200]: HTTP Error 503: Service Temporarily Unavailable'
  redirected: false
  server: nginx
  status: 503
  url: http://nyc1-apiserver-1.example.com/api/v1/healthcheck

PLAY RECAP ***********************************************************************************
nyc1-apiserver-1.example.com : ok=5    changed=3    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0   

Ini adalah pemeriksaan sederhana yang dapat dimasukkan ke dalam hampir semua pedoman untuk menambahkan jaminan keamanan yang lebih baik sebelum melakukan pekerjaan yang mengganggu atau untuk memastikan bahwa pekerjaan yang mengganggu berhasil sebelum dikatakan berhasil.

Penguraian JSON yang dikembalikan

Contoh sebelumnya berfungsi dengan baik untuk pemeriksaan kesehatan sederhana berbasis status HTTP. Namun, Anda biasanya ingin mengambil beberapa data dari titik akhir web dan kemudian melakukan sesuatu dengan data yang dikembalikan. Misalnya:Bagaimana jika saya ingin memeriksa versi aplikasi melalui titik akhir yang terbuka dan hanya melakukan pembaruan jika tidak mutakhir?

Aplikasi demo saya memiliki titik akhir seperti itu. Saat ditanya, ia mengembalikan versi aplikasi saat ini:

fsh$ http nyc1-apiserver-1.example.com/api/v1/appVersion
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 24
Content-Type: application/json
Date: Fri, 11 Sep 2020 18:36:15 GMT
ETag: "5f5bc33b-18"
Last-Modified: Fri, 11 Sep 2020 18:34:35 GMT
Server: nginx

{
    "appVersion": "1.0.1"
}

Catatan :Penasaran dengan perintah HTTP yang saya jalankan? Lihat artikel rekan sudoer saya Jonathan Roemer tentang HTTPie.

Saya dapat menggunakan JSON yang dikembalikan dari titik akhir ini untuk membuat keputusan di buku pedoman Ansible saya. Versi sebelumnya dari pedoman ini akan selalu menjalankan skrip pembaruan aplikasi. Namun, saya dapat memperbaikinya dengan hanya memperbarui aplikasi jika tidak memenuhi persyaratan versi yang saya inginkan:

---

- hosts: all
  vars:
    desired_app_version: "1.0.1"
  tasks:

    - name: Check API version
      uri:
        url: "http://{{ ansible_host }}/api/v1/appVersion"
      register: api_version_result

    - name: Perform maintenance tasks
      block:
        - name: Run maintenance start script
          command:
            cmd: /usr/local/sbin/start_maintenance.sh

        - name: Confirm that 503 Unavailable response is returned
          uri:
            url: "http://{{ ansible_host }}/api/v1/healthcheck"
            status_code: 503

        - name: Update application
          command:
            cmd: /usr/local/sbin/update_app.sh

        - name: Run maintenance end script
          command:
            cmd: /usr/local/sbin/end_maintenance.sh

        - name: Confirm that 200 OK response is returned
          uri:
            url: "http://{{ ansible_host }}/api/v1/healthcheck"
            status_code: 200

        - name: Check API version after updates
          uri:
            url: "http://{{ ansible_host }}/api/v1/appVersion"
          register: updated_api_version_result
          failed_when: updated_api_version_result['json']['appVersion'] != desired_app_version
      when: api_version_result['json']['appVersion'] != desired_app_version

Buku pedoman ini memperkenalkan beberapa konsep Ansible yang berguna. Pertama, Anda dapat melihat bahwa modul URI menjangkau /api/v1/appVersion Titik akhir API dan mendaftarkan output dari panggilan URI ini ke variabel. Tugas pembaruan telah dipindahkan ke dalam blok, yang memungkinkan pengelompokan tugas secara logis. Penambahan kapan klausa menyebabkan blok ini hanya dijalankan jika versi aplikasi saat ini berbeda dari versi aplikasi yang diinginkan, seperti yang ditampilkan oleh /api/v1/appVersion titik akhir. Terakhir, saya telah menambahkan pemeriksaan tambahan ke proses pembaruan. Setelah pembaruan dijalankan, panggilan lain ke /api/v1/appVersion endpoint memastikan bahwa pembaruan berhasil dan versi aplikasi saat ini cocok dengan versi yang diinginkan. Ini menggunakan sintaks failed_when, yang memungkinkan Anda untuk menentukan kriteria kegagalan spesifik untuk tugas.

Dinyatakan dalam bahasa sederhana, logika blok Ansible ini mengatakan:“Hanya jalankan skrip pemeliharaan dan instalasi aplikasi jika versi aplikasi saat ini tidak memenuhi versi aplikasi yang diinginkan. Setelah pembaruan selesai, pastikan aplikasi benar-benar telah diperbarui.”

Dengan hanya menggunakan beberapa baris kode Ansible, saya telah menulis cara yang ampuh namun sederhana untuk menggunakan JSON yang dikembalikan dari titik akhir API untuk membuat keputusan cerdas di buku pedoman saya.

Berinteraksi dengan titik akhir yang diautentikasi

Sejauh ini, saya telah membahas interaksi dengan titik akhir API yang tidak memerlukan autentikasi. Namun, Anda mungkin paling terbiasa berinteraksi dengan API yang memerlukan beberapa jenis autentikasi, seperti token API. Modul URI mendukung ini dengan menyetel header dan isi permintaan HTTP.

[ Anda mungkin juga menikmati:9 panduan yang memungkinkan untuk membantu Anda mempermudah otomatisasi ]

Saya dapat mengambil buku pedoman pemeliharaan saya selangkah lebih maju dengan menonaktifkan dan mengaktifkan kembali peringatan pada setiap host di sistem pemantauan saya. Ini memerlukan pengiriman POST permintaan ke titik akhir API di server pemantauan. Permintaan harus berisi token API saya dan Host di dalam badan yang disandikan JSON. Ansible membuat ini sederhana. Inilah buku pedoman terakhir:

---

- hosts: all
  vars:
    desired_app_version: "1.0.1"
    api_token: "8897e9a6-b10c-42c8-83a2-c83e9c8b6703"
  tasks:

    - name: Check API version
      uri:
        url: "http://{{ ansible_host }}/api/v1/appVersion"
      register: api_version_result

    - name: Perform maintenance tasks
      block:
        - name: Disable host in monitoring
          uri:
            url: "http://nyc1-monitoring-1.example.com/api/v1/startMaintenance"
            method: POST
            headers:
              X-API-KEY: "{{ api_token }}"
            body_format: json
            body:
              host: "{{ ansible_host }}"

        - name: Run maintenance start script
          command:
            cmd: /usr/local/sbin/start_maintenance.sh

        - name: Confirm that 503 Unavailable response is returned
          uri:
            url: "http://{{ ansible_host }}/api/v1/healthcheck"
            status_code: 503

        - name: Update application
          command:
            cmd: /usr/local/sbin/update_app.sh

        - name: Run maintenance end script
          command:
            cmd: /usr/local/sbin/end_maintenance.sh

        - name: Confirm that 200 OK response is returned
          uri:
            url: "http://{{ ansible_host }}/api/v1/healthcheck"
            status_code: 200

        - name: Check API version after updates
          uri:
            url: "http://{{ ansible_host }}/api/v1/appVersion"
          register: updated_api_version_result
          failed_when: updated_api_version_result['json']['appVersion'] != desired_app_version

        - name: Re-enable host in monitoring
          uri:
            url: "http://nyc1-monitoring-1.example.com/api/v1/stopMaintenance"
            method: POST
            headers:
              X-API-KEY: "{{ api_token }}"
            body_format: json
            body:
              host: "{{ ansible_host }}"

      when: api_version_result['json']['appVersion'] != desired_app_version

Saya sekarang menggunakan modul URI untuk mengirim HTTP POST permintaan (sebagai ganti GET default default permintaan) ke /api/v1/startMaintenance dan /api/v1/stopMaintenance titik akhir di nyc1-monitoring-1.example.com . Permintaan ini berisi token API saya untuk server pemantauan di header, dan nama host server disertakan di badan. Jika salah satu permintaan gagal dengan non-200 kode status, maka seluruh buku pedoman Ansible akan gagal.

Catatan :Dalam praktiknya, Anda akan ingin menggunakan sesuatu seperti Ansible Vault untuk menyimpan token API, alih-alih menempatkannya langsung di playbook.

Kumpulan tugas terakhir ini memungkinkan saya untuk sepenuhnya mengotomatiskan alur kerja pemutakhiran:Melakukan pemeriksaan versi, berinteraksi dengan pemantauan eksternal untuk menonaktifkan peringatan untuk suatu sistem, dan memastikan bahwa server mengembalikan kode status HTTP yang benar sebelum dan sesudah patch. Sekarang saya memiliki alur kerja ujung ke ujung yang mengotomatiskan banyak langkah umum yang saya ikuti saat melakukan peningkatan pada sistem.

[ Butuh lebih banyak tentang Ansible? Ikuti kursus tinjauan teknis gratis dari Red Hat. Ansible Essentials:Kesederhanaan dalam Tinjauan Teknis Otomasi. ] 

Menutup

Artikel ini dimulai dengan buku pedoman sederhana yang melakukan pemeriksaan web dasar terhadap titik akhir API yang tidak diautentikasi. Saya membawa Anda melalui parsing tanggapan JSON dan bahkan berinteraksi dengan titik akhir API yang diautentikasi dengan menyetel tajuk khusus dan konten isi pada permintaan HTTP. Ansible memudahkan interaksi dengan layanan web, dan saya yakin Anda akan menemukan kegunaan untuk jenis pendekatan ini, bahkan di lingkungan yang sederhana.

Jika Anda ingin belajar lebih banyak dan menantang diri sendiri, berikut adalah beberapa ide untuk diterapkan sendiri:

• Gunakan modul URI untuk berinteraksi dengan layanan web berbasis API favorit Anda.
• Lihat apakah Anda dapat mengetahui cara melakukan autentikasi dengan sertifikat klien.
• Pelajari cara mengirimkan formulir ke situs web menggunakan Ansible.