Get best of the week

Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 6. Meluncurkan aplikasi

Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 1. Pendahuluan
Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 2. Konfigurasi
Cara menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 3. Versi
Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 4.
Pengemasan perangkat lunak Bagaimana menjadi insinyur DevOps dalam enam bulan atau bahkan lebih cepat. Bagian 5. Penyebaran Foto



di atas menunjukkan kecepatan penyebaran aplikasi tradisional. Dan jika Anda menghabiskan satu bulan untuk pelatihan, sekarang Anda berada pada tahap 5 dari peta jalan:



Siap diluncurkan?


Jadi, kami memiliki kode kami yang ditulis, dikemas dan digunakan di suatu tempat. Saya memutuskan untuk mengabaikan penyebaran kode sebagai artefak mesin yang tidak dapat diubah (seperti EC2) dan fokus pada kontainer. Mengapa?

Karena memanggang AMI abadi dalam kode sumber, menyalinnya di mana-mana dan kemudian menjalankannya sangat sulit. Ini adalah template yang bagus, tetapi hanya jika benar-benar diperlukan. Oleh karena itu, saya mendorong Anda untuk mempertimbangkan apakah Anda benar-benar perlu melakukan hal itu, dan jika tidak, maka cobalah untuk mengatur kembali layanan microsoft Anda ke dalam wadah atau fungsi tanpa server.

Jika wadah tidak memungkinkan, karena Anda memutuskan untuk menulis, mengemas dan menggunakan perangkat lunak Anda sebagai aplikasi monolitik, maka pertimbangkan templat AMI yang tidak dapat diubah. Lakukan hal yang sama jika Anda perlu menjalankan aplikasi non-cloud Anda sendiri atau perangkat lunak komersial yang diberikan apa adanya (sebagaimana adanya). Namun, ini bukan topik utama dari artikel ini.

Jika kita memiliki wadah yang dikemas dengan rapi, bagaimana kita meluncurkannya?

Kontainer yang benar-benar berfungsi


Hal paling sederhana yang dapat Anda lakukan adalah menjalankan buruh pelabuhan menjalankan perintah myImage dan mengakhirinya. Tapi ini bukan ide yang baik, karena solusi seperti itu tidak berfungsi jika:

  • wadah ini tiba-tiba akan "mati";
  • Anda harus memiliki lebih dari satu wadah untuk menangani beban
  • Anda perlu menerapkan penyebaran tanpa downtime;
  • Anda ingin kontrol penuh atas layanan microser Anda
  • Anda ingin menggunakan CI / CD conveyor untuk dengan cepat mengirimkan produk ke pelanggan
    , dll ...

Dengan kata lain, apa yang terjadi ketika Anda perlu membuat aplikasi tingkat perusahaan terdistribusi yang benar? Jelas, ini adalah proses yang sedemikian rumit sehingga perintah primitif docker run tidak bisa mengatasinya.

Perhatikan bahwa teknologi perintah docker-compose menderita serangkaian masalah yang sangat mirip. Susunan Docker, yang memungkinkan Anda menjalankan banyak layanan dengan satu perintah, tidak dimaksudkan untuk penggunaan produksi. Tujuannya adalah pembuatan prototipe lokal, pengujian fungsional cepat, atau penyebaran skala sangat kecil (misalnya, rumah pribadi). Singkatnya, ini adalah alat untuk beban kerja pengguna yang tidak menghasilkan pendapatan bisnis.

Jadi, orkestra kontainer bergegas untuk menyelamatkan!

Ikhtisar metode orkestrasi wadah


Seperti semua hal lain dalam hidup, ada lebih dari satu cara untuk menyelesaikan masalah. Yang pertama dan paling jelas adalah Kubernetes . Terlahir dari proyek internal Google, Kubernetes adalah standar de facto untuk orkestrasi wadah.



Selain itu, ini adalah satu-satunya opsi jika Anda menjalankan aplikasi di:

  • pusat data pribadi;
  • Google Cloud
  • Microsoft Azure
  • cloud publik lainnya.

Namun, jika Anda bekerja di AWS, Anda memiliki satu opsi lagi - ECS. Meskipun, sebenarnya, ini tidak sepenuhnya benar: Anda memiliki Nomad dari Hashicorp (ini adalah orang yang sama yang memberi Anda Terraform) dan Anda memiliki Docker Swarm dari Docker. Masalahnya adalah bahwa ada banyak platform niche dengan implementasi minimal, jadi demi pertumbuhan karir yang cepat, kami mengabaikannya.
Pokoknya, kembali ke AWS Elastic Container Services (ECS). Ini adalah layanan orkestrasi kontainer yang dikelola sepenuhnya, cukup sederhana untuk memulai, yang terintegrasi erat dengan ekosistem AWS lainnya. Dia hanya melakukan beberapa hal, tetapi dia melakukannya dengan baik. Singkatnya, ini agak kebalikan dari Kubernetes, dan jika ECS cukup baik untuk McDonald's, maka itu mungkin cukup baik untuk Anda juga.

Namun, murni dalam hal peningkatan karir langsung, tidak ada keraguan bahwa Kubernetes adalah pilihan terbaik. Meskipun saya bertaruh bahwa 99% perusahaan yang bekerja di AWS akan sangat memuaskan ECS.

Jadi sekarang Anda bisa menentukan pilihan. Jika Anda benar-benar noob di bidang ini, Anda bisa marah dengan Kubernetes, karena di luar tim insinyur DevOps yang berpikiran sama yang dapat mendukung Anda dalam perjalanan Anda bukanlah tugas yang mudah! Gambar di bawah ini menunjukkan bagaimana seorang insinyur DevOps masa depan sedang mengeksplorasi sistem akses berdasarkan peran Kubernetes.



Namun, ini sangat mungkin, terutama dengan penawaran gratis Google dan AWS, tutorial YouTube / Udemy, dan harga spot AWS. Jika Anda memilih rute ini, saya sarankan Anda mulai dengan Google Tier Platform gratis atau tingkat kops, yang meluncurkan instance AWS spot. Kubernetes (EKS) yang berjalan di Amazon membutuhkan biaya dan, meskipun cocok untuk beban kerja prod, bukan cara yang baik untuk mulai mempelajari cara menjalankan aplikasi dengan benar. Dan saya tidak cukup tahu tentang Azure untuk merekomendasikannya.
Namun, jika Anda bukan orang baru di area ini dan benar-benar bekerja dalam ekosistem AWS, saran saya adalah sebagai berikut. Jadikan layanan microser Anda kemas dan gunakan untuk ECS untuk tidur nyenyak di malam hari dan bekerja secara paralel untuk menciptakan platform Kubernet kelas dunia. Faktanya adalah bahwa menenggelamkan diri Anda di Kubernetes seperti "mencukur yak," yang bahkan tidak dapat Anda bayangkan, dan pasti akan mengalihkan Anda dari misi sejati Anda - dengan cepat dan efisien mengirimkan produk ke pelanggan.

Catatan: "Yak shaving" adalah istilah pemrograman yang berarti serangkaian tugas yang harus diselesaikan sebelum proyek dapat maju ke tonggak sejarah berikutnya. Itu diciptakan oleh Carlin Vieri, terinspirasi oleh episode "The Ren & Stimpy Show". Nama istilah ini mengisyaratkan kesia-siaan tugas yang dilakukan, bahkan jika mereka mungkin diperlukan untuk memecahkan masalah yang lebih besar.

Apakah Anda benar-benar membutuhkan Kubernetis? Tidak. Dan jika Anda benar-benar ingin bekerja dengannya? Lalu ya ". Bersih? Pasar mengatakan: "baik Kubernetes atau pulang." Jadi mari kita lihat apa yang Anda berlangganan dengan menghubungi hal ini.

Pertama, terlepas dari kesan teknologi canggih, gagasan Kubernetes relatif lama. Ketika Google menghapus pembungkus dari Borg (pendahulu Kubernetes) pada tahun 2015, itu sudah merupakan ide yang cukup lama.

Baca ini: "Kami memberikan deskripsi singkat tentang arsitektur dan fitur sistem Borg, keputusan desain penting, analisis kuantitatif dari beberapa keputusan politiknya, dan analisis kualitatif pelajaran yang dipetik dari sepuluh tahun pengalaman bekerja dengannya." Baca lagi! Pada 2015 (!), Google membagikan rincian peluncuran sistem yang mirip dengan Kubernetes, yang pada waktu itu berusia lebih dari sepuluh tahun.



Namun, mereka sendiri tidak malu-malu. Berikut ini adalah kalimat pertama di beranda Kubernetes: “Kubernetes (K8s) adalah sistem sumber terbuka untuk mengotomatiskan penyebaran, penskalaan, dan pengelolaan aplikasi kemas. Ini mengelompokkan wadah yang menyusun aplikasi menjadi blok logis untuk kemudahan manajemen dan penemuan. Kubernet dibangun berdasarkan pengalamannya selama 15 tahun dengan beban kerja Google, dikombinasikan dengan ide dan praktik terbaik komunitas. "

Jadi, lain kali Anda mendengar seseorang yang menghadirkan Kubernetes sebagai ide "panas" baru, siap mengambil alih dunia, ingatlah bahwa ia adalah singkatan dari teknologi yang sekarang setidaknya berusia lima belas tahun. Bukankah itu sedikit inovatif?
Kedua, pikirkan tentang target audiens. Google menciptakan alat untuk menyelesaikan masalah Google dan Google. Sekali lagi, beranda Kubernetes mengatakan dengan sangat jelas tentang hal ini: "Skala planet: dirancang dengan prinsip yang sama yang memungkinkan Google untuk meluncurkan miliaran kontainer per minggu, Kubernetes dapat meningkatkan skala tanpa meningkatkan tim ops Anda."

Akhirnya, salah satu pengembang Kubernetes asli dan pendukungnya yang paling aktif, Kelsey Hightower, juga menekankan poin ini: “Kubernet adalah untuk orang yang membangun seluruh platform. Jika Anda seorang pengembang yang membuat platform Anda sendiri (AppEngine, Cloud Foundry atau klon Heroku), Kubernetes adalah yang Anda butuhkan. "

Jadi, jika Anda bekerja pada skala planet, atau meluncurkan miliaran kontainer per minggu, atau membuat cloud untuk pengguna lain, Kubernetes adalah pilihan yang tepat. Dan jika tidak, maka ini bukan akhir dari cerita. Dan saya tidak peduli bahwa nenek Anda membaca sekumpulan tweet Kelsey selama istirahat makan siang, dan kemudian mengonversi situs web toko bunga miliknya ke Kubernetes dalam seminggu menggunakan CI / CD dan Analisis Canary Automated. Ini bukan alat yang tepat untuk Anda, kecuali sifat produk Anda mengharuskan Anda untuk menggunakannya.

Tetapi apakah itu benar-benar penting? Kubernetes = $$$. Jadi naik level, nikmati perjalanan Anda ke dunia DevOps dan bagikan pengalaman Anda dengan saya.
Catatan Penerjemah: Artikel # 7 tentang aplikasi pemantauan berdasarkan ELK Stack belum dipublikasikan.

Akan dilanjutkan segera ...

Sedikit iklan :)


Terima kasih untuk tetap bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda, cloud VPS untuk pengembang dari $ 4,99 , analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).

Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang Cara Membangun Infrastruktur Bldg. kelas c menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?

More articles:


All Articles