So I decided to take matters into my own hands — literally — by building a custom split keyboard that better fit my ergonomic needs. The result? Not only did I learn a lot through the process, but my RSI pain is now completely gone after just two months of daily use.

Cardboard and Printed Layout

Before I jump and build the real keyboard, I wanted to get feel of split keyboard first, and since I don’t have access to it yet, I decided to just print it on the paper and just try to lay my hand there.

Next, after I get the feel on what kind of layout I wanted, I started with a simple prototype. I printed out a layout based on an ortholinear QWERTY design, lay it on top of cardboard and then started to make a hole for the MX-style switches. This early test helped me understand how my fingers would travel across the keys and how much spacing felt natural.

I didn’t want to switch to something like Dvorak or Colemak because sometimes I still wanted to be able to use my laptop built-in keyboard. So, I wanted to keep the familiar QWERTY layout but remove the traditional staggered rows — which I’ve come to realize aren’t really ergonomic at all. Ortholinear was the perfect middle ground: it’s cleaner, easier on the hands, and still intuitive.

Building the Case with a CNC Machine

Because I don’t have a 3D printer, I took a different route. My family happens to have a CNC machine that is used to use for making their logo from acrylic for their hijab business, so I designed the keyboard case as a sandwich-style build with that.

Powered by Raspberry Pi Pico and KMK Firmware

For the brains of the keyboard, I chose the Raspberry Pi Pico, this is because its cheaper compared to the other such as pro micro or nice!nano — one for each half. I’m running KMK firmware, a Python-based firmware built for custom keyboards. KMK is especially nice if you’re already comfortable with Python; it makes defining layers, combos, and key behavior straightforward.

2 Months In: No More RSI

After two months of using this keyboard as my daily driver, the results are clear: my wrist pain is gone. The split design lets me keep my shoulders relaxed and wrists straight, while the ortholinear layout reduces finger movement strain. It’s a night-and-day difference from standard keyboards for me.

What’s Next: Making It More Portable

Right now, the keyboard uses MX-style switches, which are pretty bulky. For my next build, I’m exploring low-profile switch options to make a more portable version — something I can toss into a backpack and use on the go. I’m also considering integrating a custom cable solution or going wireless if power efficiency allows.

Final Thoughts

This project started as a way to deal with wrist pain, but it ended up becoming one of the most satisfying and useful DIY builds I’ve ever done. I combined software, hardware, and a bit of CNC machining to create something uniquely mine — and it solved a real problem.

If you’ve ever struggled with RSI or just want to try something ergonomic and custom, I highly recommend diving into the world of DIY keyboards. You don’t need a 3D printer, and you don’t need to switch to a weird layout — just start simple and iterate. Even there’s a lot of pre-made, read-to-build custom split keyboard that is available in some eCommerce website, you probably wanted to go that route if you prefer to just build it.

NeoVim Plugin

• mfussenegger/nvim-dap
• kristijanhusak/vim-dadbod-ui

Project Directory Structure

Assuming we have this project directory structure:

src
└── App.php -- This is the entry point for CLI app
index.php   -- This is the entry point for Server app
composer.json
flake.nix   -- Nix flake file (NixOS)
.user.ini   -- PHP ini configuration
.vscode
└── launch.json -- Launch configuration

I am currently using Nix package manager to setup environment for each project that I have. With nix it is much more convenient to setup PHP environment since I can enable and include necessary PHP extension that I need to have, in this case I need to have xdebug extension.

flake.nix:

{
  description = "debugphp";

  inputs = {
    nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
    nix-shell.url = "github:loophp/nix-shell";
    systems.url = "github:nix-systems/default";
  };

  outputs =
    inputs@{
      self,
      flake-parts,
      systems,
      ...
    }:
    flake-parts.lib.mkFlake { inherit inputs; } {
      systems = import systems;

      perSystem =
        {
          config,
          self',
          inputs',
          pkgs,
          system,
          lib,
          ...
        }:
        let
          php = pkgs.api.buildPhpFromComposer {
            src = inputs.self;
            php = pkgs.php83; # Change to php56, php70, ..., php81, php82, php83 etc.
          };
        in
        {
          _module.args.pkgs = import self.inputs.nixpkgs {
            inherit system;
            overlays = [ inputs.nix-shell.overlays.default ];
            config.allowUnfree = true;
          };

          devShells.default = pkgs.mkShellNoCC {
            name = "php-devshell";
            buildInputs = [
              php
              php.packages.composer
              pkgs.phpunit
            ];
          };

          apps = {
            # nix run .#composer -- --version
            composer = {
              type = "app";
              program = lib.getExe (
                pkgs.writeShellApplication {
                  name = "composer";

                  runtimeInputs = [
                    php
                    php.packages.composer
                  ];

                  text = ''
                    ${lib.getExe php.packages.composer} "$@"
                  '';
                }
              );
            };

            # nix run .#phpunit -- --version
            phpunit = {
              type = "app";
              program = lib.getExe (
                pkgs.writeShellApplication {
                  name = "phpunit";

                  runtimeInputs = [ php ];

                  text = ''
                    ${lib.getExe pkgs.phpunit} "$@"
                  '';
                }
              );
            };
          };
        };
    };
}

composer.json:

{
    "name": "ajiyakin/debugphp",
    "description": "Sample project to demonstrate how to debug PHP in NeoVim",
    "type": "project",
    "require": {
        "guzzlehttp/guzzle": "^7.9"
    },
    "require-dev": {
        "phpunit/phpunit": "^8.5",
        "ext-xdebug": "*",
        "phpunit/php-code-coverage": "^7.0"
    },
    "license": "MIT",
    "autoload": {
        "psr-4": {
            "Ajiyakin\\Debugphp\\": "src/"
        }
    },
    "authors": [
        {
            "name": "AjiYakin",
            "email": "ajiyakin91@gmail.com"
        }
    ]
}

.vscode/launch.json:

{
  "$schema": "https://raw.githubusercontent.com/mfussenegger/dapconfig-schema/master/dapconfig-schema.json",
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug",
      "type": "php",
      "request": "launch",
      "port": 9003
    },
    {
      "name": "Built-in Server with Xdebug",
      "type": "php",
      "request": "launch",
      "runtimeArgs": [
        "-S", "localhost:8080"
      ],
      "port": 9003
    }
  ]
}

.user.ini (per-directory php ini configuration file):

xdebug.mode=debug
xdebug.client_host=0.0.0.0
xdebug.client_port=9003
xdebug.start_with_request=yes
xdebug.idekey=NEOVIM

For CLI App

Here is running order for CLI App:

1. Add breakpoint in App.php
2. Run the Listen for Xdebug from launch configuration
3. Run the cli with command: XDEBUG_CONFIG="idekey=NEOVIM" php -c .user.ini ./vendor/bin/phpunit src/App.php

For Server App

It is much more simple to run server app:

1. Add breakpoint in index.php
2. Run Built-in Server with Xdebug
3. Trigger breakpoint by sending request to the corresponding routing/endpoint.

Notes

I am not sure why the server is not shutting down when I stop the debugger for server app, I will need to figure out later, but a workaround for this is to manually kill the server with this command:

sudo kill -9 $(lsof -t -i tcp:8080)

Buku ini mencoba memberikan gambaran tentang bagaimana susahnya berharap terhadap sesuatu atau seseorang lalu kemudian kita berharap sesuatu atau seseorang tersebut akan persis sesuai dengan apa yang kita harapkan, yang akhirnya kita akan memberikan perhatian lebih terhadap hal ini, dan perhatian inilah yang akan membuat kita lupa untuk hanya mengerjakan apa-apa yang sebenarnya penting buat kita saja. Perhatian berlebihan ini yang bisa membuat orang menyalahkan keadaan, menyalahkan orang lain, menyalahkan lingkungan dan mungkin dalam tingkat yang lebih parah kita bisa jadi malah ikut campur sama urusan orang diluar keharusan kita. Ikut campur disini tidak hanya langsung berinteraksi yah, tapi “sekedar ikut memikirkan” atau bahkan silent judgment juga menurut saya sudah bagian dari ikut campur.

Kata-kata yang paling saya ingat dalam buku tersebut adalah

Kita tidak bertanggung jawab untuk apa yang orang lain lakukan terhadap kita, tapi kita bertanggung jawab penuh terhadap reaksi yang kita lakukan terhadap sikap seseorang tersebut.

Pada tahap ini saya sudah tidak mau lagi berharap sesuatu atau seseorang itu menjadi apa yang saya fikirkan, tapi kalo ada kesempatan yang bisa saya bantu untuk menjadikan sesuatu atau seseorang itu lebih baik ya saya coba bantu. Dengan begini, saya tidak lagi repot dengan kekecewaan, saya jadi lebih sadar tentang apa yang sebenarnya harus saya lakukan. Dan pastinya jadi lebih less stress.

Kalo lagi ngomongin mencoba mengubah apa yang diluar kendali kita itu saya jadi teringat pepatah, saya sendiri lupa siapa yang mengatakannya, pepatahnya seperti ini

Ketika remaja, saya berusaha mengubah dunia. Ketika dewasa saya berusaha mengubah lingkungan saya, dan sekarang saya hanya berusaha mengubah diri saya sendiri.

Jadi buat saya, sudah cukup berharap pada sesuatu atau seseorang, cukuplah berharap pada yang pasti tidak mengecewakan, yaitu Alloh SWT. Dan mulailah mengubah diri sendiri karena itu yang paling mudah dilakukan dan kita punya kontrol penuh terhadap diri kita sendiri.

Tulisan ini agak sedikit melenceng dari kebiasa saya, yaitu hanya menulis soal teknikal di blog ini. Tapi ya apa boleh buat, saya ingin mendokumentasikan apapun yang saya pelajari dalam hal apapun. Semoga ini bisa menjadi pelajaran juga bagi yang membaca.

Laptop Saya adalah Lenovo Flex 14. Laptop kantor sebenarnya, lol :)

Soal penyebabnya, Saya masih ragu sebenarnya, namun gambaran besarnya adalah karena kernel Linux versi 5.3 yang sekarang nempel di Ubuntu 18.04 Saya itu ada bug yang entah bagaimana gagal membunuh semua proses yang jalan di komputer Saya tersebut. Berikut referensi yang berkaitan dengan masalah ini:

• https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1594023
• https://askubuntu.com/questions/125844/shutdown-does-not-power-off-computer
• https://unix.stackexchange.com/questions/457967/shutdown-does-not-power-off-why

Untuk fix, ada dua solusi yang Saya temukan dari deretan resource diatas, nambah acpi=force di grub pada saat linux dijalankan, dan yang kedua adalah upgrade kernel. Saya sudah coba yang pertama, set GRUB_CMDLINE_LINUX_DEFAULT di file grub menjadi

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi=force"

dari yang asalnya

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

yang, ternyata tidak berhasil, komputer Saya tetap tidak bisa mati secara normal. LCD screen mati, tapi backlight keyboard tetap nyala, pun tombol power tetap mengindikasikan nyala, kipas ya juga sama masih kedengaran tetep muter.

Solusi yang berhasil adalah yang kedua, yaitu upgrade kernel Linux, meskipun sebenarnya agak takut juga karena takutnya malah gagal dan, ya harus benerin dari awal. Ini bukan takut sih, tapi lebih ke males :smile:

Saya coba lihat versi kernel Linux terakhir, ternyata yang terakhir dirilis (versi stable) adalah 5.6.14 sementara yang terinstall di komputer Saya adalah 5.3. Ya sudah Saya putuskan coba install yang terakhir tersebut.

Cara installnya Saya ikutin langkah-langkahnya sesuai yang ada di sini:

https://www.tecmint.com/upgrade-kernel-in-ubuntu/

Kurang lebih download file berikut

linux-headers-5.6.14-050614_5.6.14-050614.202005200733_all.deb
linux-headers-5.6.14-050614-generic_5.6.14-050614.202005200733_amd64.deb
linux-image-unsigned-5.6.14-050614-generic_5.6.14-050614.202005200733_amd64.deb
linux-modules-5.6.14-050614-generic_5.6.14-050614.202005200733_amd64.deb

dari sini: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.6.14/

Setelah itu install semua file tersebut dengan perintah: sudo dpkg -i *.deb

Catatan:

Pada saat nginstall, ada warning, kurang lebih warningnya mengatakan bahwa ada beberapa firmware yang hilang dibawah folder /lib/firmware/amdgpu/. Salah satu firmware yang hilang adalah navi12_asd.bin tapi setelah Saya coba cari-cari di repo firmware linuxnya gak nemu, akhirnya tidak Saya hiraukan warning tersebut, walhasil tetep jalan kok :smile:

Dan setelah langkah tersebut, reboot komputer dan setelah nyala lagi, pastiin kernel yang diinstall tadi sudah berhasil di load dengan command uname -rs, kalo yang muncul versi 5.6.14 ya berarti berhasil. Dan di kasus Saya, berhasil. Saya jadi bisa shutdown komputer Saya secara normal dan matinya sangat super cepat, gak kayak Windows yang super lemot kalo matiin komputer. Lol.

Ok, itu saja, Saya juga udah males nulisnya, bye.

Tapi sebelum Saya ngasih tau alesan kenapa bisa kejadian seperti itu, dan menceritakan bagaimana Saya nge-fix masalah tersebut, ada baiknya Saya kasih gambaran umum dulu apa itu EFS, ECS dan AWS itu sendiri. Biar yang baca, meski pemula gak bingung :smile:

AWS (Amazon Web Service)

Singkatnya ini services yang ditawarkan Amazon untuk para pengembang, terutama dilingkungan web, ya gak jauh-jauh sama cloud-computing-lah. Service yang ditawarkan juga beragam, dari mulai VPS, AWS-Lambda (bisa jalanin kodingan tanpa butuh server, maksudnya kita gak perlu set-up server), termasuk kalo yang suka ngopre IoT, AWS juga nyediain yang namanya AWS IoT, dan services yang lainnya banyak (banget), jadi gak bisa saya sebutin – lagian gak dibayar juga sama AWS-nya :smile:.

ECS (EC2 Container Service)

Sebelumnya kalo belum tahu apa itu EC2, EC2 itu ya anggaplah komputer biasa (aslinya virtual-machine). Terus, nyambungnya sama ECS apaan? ECS sendiri sebenarnya (kalo saya bilang) service yang disediain AWS untuk manage docker yang ada di EC2-nya itu sendiri. Apa itu docker? Kayaknya yang ini tolong cari tahu sendiri ya :smile: ECS ini ketika kita buat instance docker (container – docker run kalo di lokal komputermu) akan membuat sendiri EC2 instance untuk nyimpen container docker-nya tersebut, juga, kalau kita jalanin 2 atau lebih docker container ya ECS bisa kita set supaya nambah sendiri (kalo misal kurang) EC2-nya.

EFS (Elastic File System)

Kalo yang ini, anggaplah storage biasa, yang bisa dilepas-pasang ke EC2 tadi itu, yang mana EC2 itu juga dipake sama ECS.

Penjelasannya singkat saja, hanya untuk memberi gambaran istilah-istilah dari masalah yang Saya coba dokumentasikan disini. Oke, kalo gitu lanjut.

Aku Mau Ngapain?

Niat Saya (sebenarnya kami, karena ini kerjaan kantor :smile:), adalah karena si ECS ini sering di-restart (tiap release – dan releasenya bisa 1-2 kali seminggu), jadi ECS gak bisa nyimpen data secara persistent, ato tetap, jadi pas di restart ya datanya ilang, sementara data yang harus di proses (yang sebelumnya di download dulu) itu lumayan besar, jadi ya risih ajah harus download berulang-ulang. Jadi ya niatnya datanya disimpen di EFS, EFSnya di mount ke ECS, nanti ECS nyimpen datanya di EFS yang ke-mount tersebut. Singkatnya gitu.

Konfigurasi

Konfigurasinya sebenarnya sudah berhasil ngikutin ini. Cuma untuk launch-configuration-nya, pake script yang sederhana, gak seribet yang ditulis di blog tersebut, kayak gini:

#!/bin/bash

# Configure ECS cluster
echo ECS_CLUSTER=<NAMA_CLUSTER_DI_ECS> >> /etc/ecs/ecs.config

# EFS configurations
yum -y install nfs-utils
mkdir -p <PATH_FOLDER_KEMANA_EFS_TSB_AKAN_DI_MOUNT>
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 <DISINI_DNS_EFSNYA> <PATH_FOLDER_KEMANA_EFS_TSB_AKAN_DI_MOUNT>

Dan ini berhasil, disebut berhasilnya gimana? Well, ngeceknya bisa pake command df -T, akan keliatan apa saja yang ke mount ke EC2 tersebut. Dan setelah coba ditulisi, berhasil juga, datanya ke store ke EFS, begitu juga kalo EFSnya dicoba di mount dari EC2 yang lain, terbaca juga EFS beserta file yang sudah disimpan tadi.

Masalah

Salahnya, Saya terlalu yakin kalo si ECS (docker) ini akan berhasil nge-mount EFS (sesuai konfigurasi path diatas) ke containernya :smile: Sampe akhirnya kejadian aneh datanya gak mau ke store di EFS. Padahal dicek dari EC2, EFSnya sudah ke mount. Dan… dicoba ditulisi dari container dockernya (yang dijalanin otomatis sama si ECS), datanya kesimpen di EC2nya doang, bukan di EFS.

Iya, Saya yang salah, tolong jangan banting gelas :smile:

Solusi

Setelah seharian berkutat, akhirnya nemu ini yang cuma disuruh restart docker daemon sama agent ECSnya doang :smile:

Dicoba…

Dan yup, berhasil. Terus kalo mau otomatis gimana? Ah biasa, disimpen di launch-configuration-nya itu loh. Tempelin script dibawah ini dipaling bawah di script launch-configuration-nya, setelah nge-mount EFSnya:

# Restart docker daemon and ecs (docker-agent),
# so docker would be able to "see" available EFS
service docker restart && start ecs

Versi lengkap launch-configuration-nya:

#!/bin/bash

# Configure ECS cluster
echo ECS_CLUSTER=<NAMA_CLUSTER_DI_ECS> >> /etc/ecs/ecs.config

# EFS configurations
yum -y install nfs-utils
mkdir -p <PATH_FOLDER_KEMANA_EFS_TSB_AKAN_DI_MOUNT>
mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 <DISINI_DNS_EFSNYA> <PATH_FOLDER_KEMANA_EFS_TSB_AKAN_DI_MOUNT>

# Restart docker daemon and ecs (docker-agent),
# so docker would be able to "see" available EFS
service docker restart && start ecs

Lesson Learned

Baca dokumentasi secara seksama

Karena ternyata, di dokumentasinya ada notes, yang persis “menyinggung” masalah ini :smile:

Dokumentasinya ada disini. Kutipan notes-nya:

For operating systems that use devicemapper (such as Amazon Linux and the Amazon
ECS-optimized AMI), only file systems that are available when the Docker daemon
is started will be available to Docker containers. You can use a cloud boothook 
to mount your file system before the Docker daemon starts, or you can restart 
the Docker daemon and the Amazon ECS container agent after the file system is 
mounted to make the file system available to your container volume mounts.

Sekian untuk hari ini, semoga bermanfaat :thumbsup:

Dan mohon do’akan supaya Saya konsisten nulis di blog karatan ini.

Okeh, akhirnya ada beberapa tools yang ternyata bisa saya gunakan untuk memaksimalkan kemampuan touch-pad saya tersebut, setelah sebelumnya cuma dipake buat scroll atas bawah pakek dua jari doang :smile:

Tools yang bisa dipake bisa macem-macem, dan ternyata secara bawaan di elementary os juga ternyata sudah ada, yaitu ginn dan setelah saya coba-coba browsing dan coba melakukan beberapa konfigurasi dengan hasil hampir 70% touch-pad saya tidak bekerja dengan baik. Sebenarnya sama ginnya (touch-pad saya kedetect) hanya saja entah kenapa ginn gak ngejalanin perintahnya. Terus saya coba-coba install aplikasi lain, dan nemulah touchegg. Awalnya agak ragu juga, soalnya direpositorynya sendiri update-an terakhir adalah 2 tahun lalu, sedangkan saya baru aja beli laptop 2 minggu yang lalu, bisa saja hardware saya tidak compatible, fikir saya. Tapi setelah saya coba akhirnya justru malah hasilnya lebih baik, dan langsung ajah saya coba cari-cari konfigurasi yang orang lain pakek buat aplikasi ini, dan akhirnya nemu juga. Saya lupa dari mana sumbernya :smile: tapi mudah-mudahan ‘mpunya’ gak ngamuk :smile: dan saya backup langsung di gists saya, supaya nanti saya bisa pakek lagi kalo suatu saat saya install ulang lagi.

Oke, berikut ini step buat masang touchegg di elementary os:

1. Install touchegg dengan command: sudo apt-get install touchegg atau build langsung dari source codenya.
2. Tambahkan file konfigurasinya, kopi dari sini, dan simpan di ~/.config/touchegg/touchegg.conf
3. Tambahkan touchegg agar dijalankan pas start-up, caranya ada di System Settings dibagian Applications dan di tab Startup dan klik tanda plus (+) di bagian kiri bawah dan tuliskan /usr/bin/touchegg lalu tekan enter.
4. Selesai, coba logout dan login lagi. Terus coba geser workspace dengan 4 jari (kekiri atau kekanan). Atau expands workspace dengan slide 4 jari kearah atas.

Itu ajah. Untuk distro linux yang lain mungkin tidak terlalu jauh berbeda :smile:

Gak lama kemudian lead saya langsung bilang “coba kamu cari-cari tentang DevOps”. Oke, CuriousMode:On.

Saya mulai baca-baca dan, yup, sekarang mulai faham langkah-langkah bagaimana proses dari mulai pembuatan aplikasi (coding) sampe ke tahap packaging dan publishing (sekalipun cuma gambaran). Saya memang programmer baru, tepatnya baru kerja.

Jujur saja, diawal saja saya kenal github saya agak aneh, kenapa harus pakai github? Kenapa gak copy-paste manual aja? Memang serepot apa sih versioning (yang dulu saya menterjemahkan mentah kata ini) sampai harus pake tools macam github segala? Sekarang saya mulai sadar dengan itu semua, ya maklumlah dulu seringnya ngoding sendiri jadi ya sekarang perlahan mulai faham apa yang membedakan antara freelancer dengan full stack programmer, salah satunya ya penggunaan tools itu. Freelancer lebih sering memilih tools yang memang ya berguna buat dia (kerja sendiri) ketimbang full stack programmer yang sering kali milih tools untuk kemudahan kolaborasi. Oke stop, balik kejalur pembahasan.

Saya jadi bingung, apa hubungannya cerita diatas sama judul?

Secara tidak langsung memang agak gak nyambung (bodo amat, blog saya ini), yang pasti, tools-tools yang saya sebutkan diatas adalah tidak lain salah satu dari tools untuk kolaborasi dalam rangka software development. Dimana sebenarnya sering kali timbul banyak masalah ketika kita ngoding bareng-bareng, entah itu pas proses penulisan kode, atau bahkan pada saat proses mau rilis aplikasi. Dan diartikel ini saya coba nulis apa yang ada dikepala saya soal proses rilis, terutama issue yang sedang “hot” akhir-akhir ini diproses rilis tersebut. Langsung mulai deh…

Bagaiamana proses rilis itu?

Sebelum saya nulis soal “apa itu DevOps?”, saya mau cerita soal bagaimana proses rilis aplikasi itu secara garis besar (tentunya ditempat saya). Ini penting karena nanti akan nyambung dengan judul diatas.

Yaiyalah, kalo gak nyambung ngapain ditulis, tulalit nih penulis.

Anggaplah sekarang kita sudah beres koding dengan keringat dingin mengucur (seember – karena deadline) dan kita akan merilisnya, dan biasanya berikut ini adalah langkah-langkah yang dilakukan:

1. Mindahin source code ke server live.
2. Melakukan beberapa konfigurasi yang dibutuhkan.

Kelihatannya simple ya?

Pada kenyataanya, sebelum mindahin kodingan ke server live biasanya ada proses menjalankan semua test yang ada di source code tersebut. Kalo sering ngelakuin TDD mungkin gak aneh yah. Kalo hasil tesnya lancar ya lanjut, kalo ada yang ‘bengkok’ ya dicek ulang, dibenerin dulu.

Proses mindahin kodingan dari tempat development ini juga beda-beda, tapi kebanyakan sudah clone langsung dari repository ketimbang ngopi atau ngupload kodingan secara manual lewat FTP. Oke, tahap ini mungkin masih dibilang gampang–lah. Sekalipun ya ribet juga harus login ke server, terus ngejalanin git clone atau git pull origin master. Belum lagi kalo lupa naro foldernya dimana, ato lupa servernya dimana (yang ini ngarang biar ‘extreme’) kan bikin repot, tapi udah terlanjur bilang gampang, ya gampangin aja lah.

Lanjut ke proses kedua, konfigurasi. Nah ini yang agak ribet. Misal sehabis mindahin source code baru kita harus ngubah beberapa settingan kayak variable development atau ngeset server jadi mode maintenance ketika proses rilis ini, ato harus nyeting cron job, dll. Proses ini yang sebenernya ribet, tapi ‘kelihatan’ gampang dan berulang-ulang, yang padahal ngabisin waktu banyak, padahal misalnya hanya salah setting cron job, salah masukin nama file misalnya.

Dari paragrap diatas sekarang mulai ada gambaran gimana proses rilis aplikasi dari tempat development ke tempat laip (red: live). Dan ya agak ribet juga, terlebih sebenarnya proses yang berulang-ulang seharusnya memang lebih baik diotomatisasi biar meminimalisir kesalahan manusia.

DevOps itu apa?

Sekarang kita baru ‘nginjek’ kata ini, DevOps sendiri menurut wikipedia dikatakan campuran kata dari Development dan Operations. Dimana ini nunjukin tugas-tugas yang berkaitan dengan proses development dan hal-hal operasional lain atau staf IT lain, ya kayak situkang ngurusin server yang tugasnya ngupload file kodingan kita ke server live tadi itu, atau bahkan QA (Quality Assurance) – atau tukang tes.

Tugas DevOps

Dari pengertian singkat diatas sekarang setidaknya kita tahu bahwa tugas DevOps itu ya jadi jembatan antara tukang koding, tukang tes, dan tukang ngurus server. Kalo memang kita sering rilis secara berkala ya sebaiknya memang aware sama pentingnya DevOps ini, terutama otomatisasi, karena tentu saja kita nggak mau kalo harus melakukan tugas berulang-ulang yang memang sebenarnya bisa diotomatisasi, yang pasti bisa menghemat waktu. Nah, untuk beberapa tools yang berkaitan dengan DevOps ini ada listnya, sebagai remainder saya juga sih, nih:

• Jenkins
• Ansible
• Selenium
• Docker
• Bamboo
• Travis CI
• dan lain-lain.

Oke, rasanya sudah capek saya nulis. Capek baca nggak? Syukurdeh (mau capek mau enggak tetep saya sukurin, haha…).

Sekian aja dulu tulisan tentang DevOps, mungkin postingan selanjutnya saya bakalan nulis tentang tutorial ato hal-hal lain yang masih berkaitan sama DevOps ini, soalnya memang lagi curious banget sama yang satu ini.

See you…

Okeh, sampai disini. Kita sama :smile: Berarti kita punya garis start yang sama.

Dikantor, kebetulan sedang ada issue tentang DevOps, lebih spesifik lagi tools/teknologi yang dipake adalah Ansible, jadinya saya penasaran dengan teknologi ini. Jadi saya fikir, daripada saya belajar sendiri mending saya sekalian share, paling tidak ini jadi catatan saya ketika saya lupa.

Kenapa harus diotomatisasi? Manual juga masih bisa kan? Toh cuma mindahin source code doang to?

Mmmm… Coba baca kebawah dulu deh :worried:

Proses Deployment Aplikasi

Proses deployment aplikasi disetiap perusahaan IT memang biasanya berbeda-beda, tergantung kebijakan dan infrastruktur yang dipilih. Namun demikian, ide dari proses deployment tersebut ‘cenderung’ sama yaitu dimulai dari pemindahan source code aplikasi dari tempat development ke server live, lalu kemudian melakukan beberapa pengaturan yang diperlukan. Nampaknya sederhana, tapi jika setiap 2 minggu atau 3 minggu atau berapapapun lamanya jarak release tersebut, tetap saja harus melakukan proses yang ‘cenderung’ berulang dan sama (dari proses sebelumnya), apa itu efektif? Menghabiskan banyak waktu dan tenaga untuk proses yang sama, dalam istilah programmer tua itu disebut DRY (Do not Repeat Yourself). Oya, belum lagi nanti kalau misal situkang mindahin source code tersebut lupa mengkonfigurasi file anu, file ini, file itu, apa tidak malah jadi merepotkan? Belum lagi kalau servernya banyak gimana?

Sebentar, lalu apa itu DevOps (lebih tepatnya “siapa”)?

Ok, pertanyaan ini sama juga pernah muncul dikepala saya, dari DevOps sendiri kata ini terdiri dari dua suku kata yaitu Dev dan Ops itu sendiri. Dev untuk Development (gak tahu deh, development atau developer :smile:) dan Ops sendiri untuk Operations. Jadi ini gabungan dari pekerjaan Development dan Operations dimana development cenderung ke pembuatan, pengembangan dan support aplikasi itu sendiri sedangkan Operations itu sendiri cenderung ke pekerjaan server administration, packaging, dll.

Sumber gambar: Wikipedia - DevOps

Jika diposisikan, DevOps itu berada di-irisan antara development (software enginereeng), Quality Assurance (QA) dan Technology Operations.

Untuk lebih jelasnya tentang tanggung jawab dari pekerjaan ini bisa merujuk ke halaman DevOps.

Sudah liat, banyak yah tanggung jawabnya. Nah justru karena itu, terkadang proses deployment jadi kelihatan ribet padahal jika di dilihat secara secara sederhana itu hanya usaha untuk memindahkan source code aplikasi dari development atau test environment ke live environment.

Ok, sekarang saya (maksud saya pembaca) mulai faham. Lalu selanjutnya apa?

Apa Itu Ansible?

Saya sudah menjabarkan masalah diatas, jadi simple-nya ya Ansible itu membantu (atau bahkan mengganti) peran situkang upload source code tadi itu.

Sudah, itu saja, kebanyakan teori malah jadi bosan nanti.

Cara Kerja Ansible

Mmm… Sederhana saja, saya sudah mau ke praktek ya.

Pernah pake SSH? Kalo belum tahu silahkan baca-baca dulu deh apa itu SSH!

Ansible make SSH. Untuk proses yang lebih kompleks lagi Ansible pake library Python, tapi ya ujung-ujungnya, pake SSH itu tadi :smile:.

Praktek

Sudah install Ansible?

Sebenarnya saya lupa untuk membuat postingan tentang cara instalasi Ansible sendiri :smile:. Untuk sementara silahkan merujuk ke halaman dokumentasinya disini.

File configurasi (default) Ansible.

Letak file-file configurasi Ansible sebenarnya berbeda-beda, tergantung environment yang digunakan biasanya. Tapi, karena saya pake [Ubuntu], jadi saya hanya akan menuliskan yang saya tahu saja :cry:.

Lokasi konfigurasi Ansible sendiri ada di:

/etc/ansible

~/.ansible

Atau bisa langsung di dalam folder project Ansible itu sendiri. Sekarang kita akan mengintip ada apa saja difolder utama konfigurasi Ansible itu sendiri.

Kita coba ketikan perintah ls -l /etc/ansible/ (untuk linux) dan hasil dari eksekusi perintah tersebut seperti ini:

    ansible.cfg
    hosts

File ansible.cfg

File ini berisi konfigurasi utama ansible dimana secara default, jika kita tidak menggunakan file konfigurasi kita sendiri atau tidak mendeklarasikannya secara langsung di command-line. Urutan dari file konfigurasi yang akan digunakan oleh ansible adalah

• command line, perintah konfigurasi yang dituliskan langsung di terminal pada saat menjalankan ansible.
• File konfigurasi yang diletakan pada project ansible itu sendiri. Atau dimana direktori sekarang aktif.
• File konfigurasi yang diletakkan di directori home user, di linux biasanya terletak di ~/.ansible.
• Terakhir, berada di direktori utama ansible itu sendiri. Di linux sendiri, biasanya di /etc/ansible/.

File hosts

File ini berisi konfigurasi server yang akan kita lakukan konfigurasi. Secara default, file ini tidak berisi apa-apa, kecuali contoh saja.

Perintah sederhana, Ad-Hoc command

Sebelum kita bisa melakukan perintah sederhana ini, kita harus punya server yang akan kita konfigurasi dulu, untuk demo atau praktek biasanya saya menggunakan VirtualBox dan sejenisnya. Dan pastikan sudah bisa dan sukses login melalui SSH. Ini karena ansible menggunakan SSH, ingat tadi diatas!

Disini, saya menggunakan VirtualBox dan IP-nya saya setting static menjadi 192.168.56.10. Jadi saya akan mencoba mengkonfigurasi server virtual tersebut.

Ketikan perintah berikut di Terminal (ganti [username] dengan username masing-masing yang digunakan untuk mengakses komputer server):

    ansible all -u [username] --ask-pass -m ping

Perintah diatas akan melakukan ping (-m ping) ke semua (all) hosts yang kita daftarkan di file hosts tadi, dalam kasus ini hanya satu server. Dan ingat, perintah diatas dieksekusi melalui SSH dengan user (-u [username]) tertentu. Dan satu lagi, --ask-pass saya gunakan untuk memerintahkan pada ansible agar menanyakan password SSH kita ketimbang login melalui SSH key. Kedepannya saya asumsikan kita tidak perlu lagi memasukkan password untuk SSH karena kita telah melakukan setting RSA key, jika belum, silahkan lakukan. Tutorialnya banyak kok di mbah.

Dan jika suskes terkoneksi ke server, responsenya harusnya seperti ini:

    192.168.56.10 | success >> {
        "changed": false,
        "ping": "pong"
    }

Tunggu dulu, perintah untuk ngeping aja kok panjang banget? Bukannya di subjudul ditulis “perintah sederhana”?

Ya, tentu, karena kita belum melakukan konfigurasi apapun. Itu kenapa di subjudulnya saya masukkan kata Ad-Hoc.