3D: Deploy… Deploy… Dead!

Source: me.me

Pada masa pengembangan, kita tak dapat memperkirakan waktu deployment. Selain itu, bisa saja deployment dilakukan lebih dari satu kali dalam rentang waktu yang dekat. Ini artinya orang yang bertugas melakukan deployment akan sangat relate dengan meme di atas. Belum lagi jika ia harus melakukan deployment ke lebih dari satu server. Deployment juga tidak dapat dilakukan asal-asalan, karena deployment baru berkaitan dengan program yang sedang berjalan saat ini hasil deployment sebelumnya.

Deployment Strategies

Ada beberapa strategi deployment yang dapat dipilih. Semua strategi memiliki keunggulan dan peruntukannya masing-masing.

Recreate

Strategi paling simple karena hanya mengganti versi sebelumnya dengan cara mematikan langsung versi lama, lalu menyalakan versi baru. Biaya yang dibutuhkan oleh strategi ini juga murah karena tidak perlu menambah resource. Namun ada downtime pada service, sehingga strategi ini sering dapat digunakan jika layanan memang tidak diakses secara terus-menerus.

Ramped (Rolling-Update atau Incremental)

Strategi ini membuat versi terbaru menggantikan versi lama secara perlahan dan bertahap. Apabila sebuah service pada versi baru sudah menyala, maka service yang sama pada versi lama dimatikan. Proses tersebut dilakukan satu persatu hingga semua service termigrasi ke versi baru.

Blue/Green

Bisa dikatakan gabungan dua versi sebelumnya. Versi baru dinyalakan dan dipastikan berfungsi dengan benar. Kemudian traffic dipindahkan langsung seluruhnya ke service baru pada level load balancer.

Canary

Versi lebih advance dari Blue/Green karena traffic dipindahkan secara bertahap. Misal 10% ke versi baru dan 90% ke versi lama. Lalu naik secara perlahan hingga nanti 100% traffic dihandle oleh versi baru.

A/B testing

Teknik ini tidak dapat disebut sebagai teknik deployment sepenuhnya. Hal ini dikarenakan versi baru dan lama masih menyala. Teknik ini bekerja dengan cara memindahkan sebagian user dengan karakteristik tertentu ke versi terbaru. Misalnya user yang mengakses dengan smartphone dipindahkan ke versi baru, sedangkan user dengan laptop tetap menggunakan versi lama.

Shadow

Teknik ini mirip dengan Blue/Green hanya saja teknik ini melakukan replikasi traffic untuk diarahkan ke versi baru. Apabila versi terbaru dinilai stable, maka versi lama dapat dimatikan dan traffic otomatis mendapat response dari versi baru.

Deployment Pada SISKRIPSI

Untuk program SISKRIPSI, kami hanya perlu melakukan deployment ke satu server saja yakni staging, yang mana tidak harus avaible selama 24/7. Selain itu SISKRIPSI dibangun dengan arsitektur monolith, sehingga tidak mungkin kami menerapkan ramped. Oleh karenanya kami menggunakan strategi recreate.

Agar terhindar dari meme di awal post, kami juga menggabungkan proses deployment dengan pipeline gitlab. Saat branch staging diupdate, maka deployment akan dilakukan.

Berikut adalah cuplikan konfigurasi pipeline untuk melakukan deployment pada server staging.

image: python:3.8
stages:
  - test
  - deploy
.deploy_prep_script: &deploy_prep_script |-
  apt-get update -y
  apt-get install openssh-client -y
  cd ..
  tar -czf siskripsi_app.tar.gz siskripsi_app
  cd siskripsi_app
Deploy Staging:
  stage: deploy
  image: ubuntu:latest
  script:
    - *deploy_prep_script
    - chmod 400 $STAGING_KEY
    - scp -o StrictHostKeyChecking=no -i $STAGING_KEY ../siskripsi_app.tar.gz ubuntu@<staging-machine-ip>:~/siskripsi_app.tar.gz
    - ssh -q -o StrictHostKeyChecking=no -i $STAGING_KEY ubuntu@<staging-machine-ip> < .gitlab-ci/deploy.sh
  only:
    - staging

Dari konfigurasi di atas dapat terlihat bahwa menginstall seluruh depedencies terlebih dahulu. Kemudian kami mengcompress source code SISKRIPSI. Setelah itu, kami mengcopy file tersebut ke server staging dengan memanfaatkan scp, yakni melakukan copy melalui protocol SSH. Mengingat kami menggunakan SSH, maka kami membutuhkan key yang mana telah didefine melalui secret environment variable pada repository gitlab. Terakhir, kami melakukan eksekusi script deploy.sh.

Lalu, apa isi dari deploy.sh? Berikut adalah isi dari script tersebut.

rm -r /home/ubuntu/siskripsi_app
tar -xf siskripsi_app.tar.gz
source /home/ubuntu/env/bin/activate

alias pip3='/home/ubuntu/env/bin/pip3'
alias python3='/home/ubuntu/env/bin/python3'

cd /home/ubuntu/siskripsi_app

# Install dependencies
echo '=============== INSTALLING REQUIREMENTS ==============='
pip3 install -r requirements.txt

echo '=============== MAKE MIGRATIONS ==============='
python3 manage.py makemigrations

echo '=============== MIGRATE DB ==============='
python3 manage.py migrate

echo '=============== COLLECT STATIC ==============='
python3 manage.py collectstatic --no-input

# Restart the service
sudo service siskripsi_app restart

# Log last 20 logs
sudo journalctl -u siskripsi_app -n 20

Intinya adalah kami memanfaatkan systemd untuk menjalankan aplikasi kami. Maka dari itu, kami perlu mendefinisikan konfigurasi yang tepat (i.e. mendefinisikan systemd unit file). Konfigurasi ini sudah ada di dalam /etc/systemd/user saat kami membuat server staging.

[Unit]
Description=SISKRIPSI Web App

[Service]
Type=simple
ExecStart=/home/ubuntu/env/bin/gunicorn --chdir /home/ubuntu/siskripsi_app/ siskripsi.wsgi --bind 0.0.0.0:8888  --access-logfile -
Restart=always
EnvironmentFile=/home/ubuntu/.env

Akhir Kata

Strategi deployment ditentukan berdasarkan arsitektur aplikasi yang dibuat. Selain itu, pikirkan pula cost serta kemampuan yang dibutuhkan untuk melakukan deployment. Pemilihan strategi deployment yang baik adalah yang membutuhkan resource minimal namun memberikan hasil yang maksimal.

Referensi

[1] https://thenewstack.io/deployment-strategies/