Infrastruktur GitHub: kod, awan dan automasi

Apabila anda mula menggunakan infrastruktur sebagai kod dan penyepaduan GitHub, keraguan akan timbul dengan cepat: Patutkah saya menggabungkan Terraform atau CloudFormation dengan kod aplikasi? Patutkah saya membuat repositori berasingan? Bagaimanakah saya mengintegrasikan semua ini dengan GitHub Actions, GitHub Pages atau alatan seperti Ansible, Chef atau Vagrant? Realitinya ialah di sebalik GitHub dan ekosistemnya terletaknya seluruh dunia amalan, teknologi dan aliran kerja yang berbaloi untuk diterokai mengikut rentak anda sendiri.

Dalam artikel ini, kami akan meneroka dengan terperinci bagaimana infrastruktur biasanya disusun di GitHub , alatan yang digunakan di sekelilingnya (Terraform, Ansible, Chef, Vagrant, containers, Azure, dll.), bagaimana ia berkaitan dengan GitHub Pages atau GitHub Copilot, dan apa yang GitHub sendiri dan dunia akademik lakukan untuk mengajar amalan ini dalam projek dunia sebenar dan di awan.

Apakah GitHub dan mengapa ia penting kepada infrastruktur?

GitHub ialah platform pengehosan repositori Git yang telah menjadi standard de facto untuk kedua-dua projek sumber terbuka dan proprietari. Ia membolehkan anda bekerja dengan sebarang bahasa, mengintegrasikan alatan CI/CD, mengurus isu dan semakan kod, dan yang paling penting, memusatkan kitaran hayat aplikasi dan infrastruktur.

Pada peringkat profesional, ramai pembangun melihat GitHub sebagai pengganti semula jadi kepada SourceForge . Semasa tahun 2000-an, SourceForge merupakan repositori utama untuk projek sumber terbuka, tetapi populariti Git berbanding sistem seperti SVN atau CVS, ditambah pula dengan pengalaman penggunanya yang lebih baik, menyebabkan kebanyakan projek berhijrah ke GitHub. Hari ini, kedua-dua syarikat besar dan projek peribadi dihoskan di sana.

Pada tahun 2018, Microsoft telah memperoleh GitHub . Terdapat sedikit keraguan pada mulanya daripada sebahagian komuniti, tetapi dalam praktiknya platform tersebut terus berkembang tanpa sebarang perubahan operasi yang besar. Integrasi dengan ekosistem Microsoft (terutamanya dengan Azure dan alatan pembangunan) telah diperkukuh, sementara ia kekal sebagai hab pusat untuk semua jenis projek sumber terbuka.

GitHub mengehos repositori untuk platform yang digunakan setiap hari untuk mengurus infrastruktur: Ansible, Terraform, integrasi dengan Microsoft Azure, Amazon Web Services, Nutanix, Netflix dan banyak lagi. Meneroka repositori ini adalah cara yang sangat berkesan untuk melihat bagaimana pihak lain mendekati automasi, kebolehcerapan dan daya tahan.

Infrastruktur sebagai perkhidmatan dan infrastruktur sebagai kod: konteksnya

Apabila kita bercakap tentang infrastruktur GitHub dalam persekitaran profesional, kita biasanya merujuk kepada cara kita menerangkan dan mengurus infrastruktur awan dengan kod versi dalam repositori Git. Ini sejajar dengan model Infrastruktur sebagai Perkhidmatan (IaaS) dan lapisan peringkat lebih tinggi seperti PaaS.

Di lapisan awan yang paling bawah, IaaS pada asasnya terdiri daripada mesin maya, storan dan rangkaian maya . Perkhidmatan seperti Amazon EC2, S3 dan EBS menandakan permulaan model ini: contoh elastik yang boleh diskalakan naik atau turun mengikut permintaan, sangat berbeza daripada VPS tegar klasik. Pesaing seperti Microsoft Azure dan Google Compute Engine menawarkan penyelesaian yang serupa.

Di hujung spektrum yang lain, terdapat platform untuk menyediakan awan peribadi pada pusat data anda sendiri, seperti OpenStack atau OpenNebula. Kedua-duanya merupakan penyelesaian sumber terbuka yang membolehkan anda mengurus tika, rangkaian, imej dan storan tanpa bergantung pada pembekal awam.

Di atas lapisan infrastruktur ini, alat pengurusan konfigurasi dan orkestrasi memainkan peranan : Chef, Puppet, Ansible, Salt, Rex, Docker, Vagrant… Kesemuanya sangat bergantung pada GitHub, di mana resipi, buku panduan, manifes, fail Vagrant atau fail Docker yang menerangkan rupa sistem akan diversikan dan digabungkan dengan CI/CD untuk menggunakan perubahan dengan cara yang boleh diulang.

Infrastruktur sebagai kod dalam amalan: Terraform, Ansible dan syarikat

Salah satu projek utama di GitHub ialah Terraform (hashicorp/terraform). Terraform membolehkan anda menentukan keseluruhan infrastruktur (rangkaian, mesin, pangkalan data, pengimbang beban, dll.) dalam fail konfigurasi deklaratif . Fail-fail ini dianggap sebagai kod: ia disemak, diversi, diuji dan digunakan menggunakan saluran paip.

Sebaliknya, alat seperti Ansible (ansible/ansible) membolehkan anda mengautomasikan konfigurasi pelayan (memasang pakej, mengedit fail, mencipta pengguna, menggunakan perkhidmatan) menggunakan YAML dan SSH, tanpa memerlukan ejen pada mesin jauh. Buku panduan Ansible juga disimpan dalam repositori Git dan boleh dilaksanakan daripada CI/CD atau mesin orkestrasi.

Chef, Salt, Puppet dan Rex menangani keperluan yang serupa dengan pendekatan yang berbeza. Chef mentakrifkan resipi dan buku masakan yang ditulis dalam Ruby; Salt memberi tumpuan khusus pada keadaan dan skalabiliti besar-besaran; Puppet mempunyai bahasa deklaratifnya sendiri; Rex berasaskan Perl dan berguna untuk pelaksanaan jarak jauh yang mudah. ​​Kesemuanya berintegrasi dengan baik dengan GitHub sebagai sistem kawalan versi pusat.

Selain konfigurasi, alatan seperti Vagrant membantu mengurus kitaran hayat mesin maya untuk pembangunan atau pengujian. Fail Vagrant, yang juga diversikan di GitHub, menentukan kotak mana yang hendak digunakan, hipervisor mana (VirtualBox, VMware, Docker, dll.), penyedia mana (shell, Ansible, Chef, Puppet, Salt) dan konfigurasi mana yang hendak digunakan. Ini membolehkan seluruh pasukan melancarkan persekitaran yang serupa dengan satu arahan.

Bagaimana GitHub mengatur infrastrukturnya sendiri: Tindakan, Projek, Keselamatan dan Copilot

GitHub sendiri menggunakan GitHub untuk membina GitHub. Dalam ceramah dan dokumentasi mereka, mereka menerangkan bagaimana mereka menggabungkan GitHub Actions, GitHub Projects, GitHub Advanced Security dan GitHub Copilot untuk membangun dan mengendalikan platform tersebut.

Projek GitHub digunakan untuk mengurus kerja : perancangan, pengesanan isu dan pengutamaan. Ia membolehkan anda menyelaras berbilang pasukan dan repositori sambil mengekalkan keterlihatan terhadap apa yang sedang digunakan pada platform.

GitHub Advanced Security menyediakan pengimbasan kod, pengesanan rahsia dan analisis kebergantungan untuk mencegah kerentanan sebelum ia sampai ke tahap pengeluaran. Dengan cara ini, infrastruktur yang ditakrifkan dan digunakan oleh GitHub akan menjalani pemeriksaan keselamatan automatik.

Pemodenan Copilot dan infrastruktur GitHub dalam Azure

Satu kes yang amat menarik ialah ejen pemodenan GitHub Copilot , yang direka untuk aplikasi yang sedang dipindahkan atau dimodenkan dalam Azure. Ejen ini menyokong peruntukan infrastruktur, pengkontenaan dan penggunaan dalam dua fasa yang berbeza.

Fasa pertama ialah penyediaan infrastruktur . Berdasarkan input seperti kod sumber aplikasi, laporan penilaian (Azure Migrate, Modernize Assess, alat migrasi), gambar rajah seni bina atau keperluan keselamatan dan pematuhan, ejen menjana pelan untuk mencipta zon pendaratan dalam Azure (keselamatan, identiti, rangkaian, tadbir urus, dll.).

Aliran kerja biasanya bermula dengan arahan seperti `modernize plan create` , yang menyatakan dalam bahasa semula jadi apa yang diperlukan (contohnya, "create Azure infrastructure for my application") dan nama pelan. Hasilnya termasuk dokumen yang menggariskan strategi seni bina dan senarai tugasan terperinci yang perlu dilaksanakan.

Sebelum pelaksanaan, pasukan menyemak dan melaraskan pelan dan tugasan. Kemudian, arahan ` modenkan pelan laksana` akan menggunakan sumber dan menjana kod infrastruktur yang berkaitan. Semua ini boleh dan harus diversikan pada GitHub untuk memastikan kebolehkesanan perubahan.

Fasa kedua merangkumi pengkontenaan dan penggunaan . Pelan baharu dicipta untuk menjana fail Docker, mengesahkan binaan imej, menghasilkan manifes penggunaan (contohnya, untuk perkhidmatan Kubernetes atau Azure) dan skrip yang boleh digunakan semula. Sekali lagi, pelan tersebut disemak dan dilaksanakan, menyemak perubahan dengan arahan seperti `git status` atau `git diff` dan mengesahkan aplikasi pada URL akhir.

Halaman GitHub: infrastruktur statik dan penerbitan daripada repositori

Satu lagi bahagian penting dalam "infrastruktur GitHub" ialah GitHub Pages , perkhidmatan untuk menerbitkan laman web statik terus daripada repositori. Walaupun ia mungkin kelihatan mudah, ia juga melibatkan keputusan tentang cara menstrukturkan kod, kandungan, membina aliran kerja dan cabang laman web.

Untuk mencipta laman web dengan GitHub Pages, anda memerlukan repositori untuk laman web iniAnda boleh mencipta yang baharu atau menggunakan semula yang sedia ada. Jika ia merupakan laman web pengguna atau organisasi, nama repositori mesti mengikut corak tersebut. usuario.github.io u organizacion.github.ioSentiasa dalam huruf kecil. Untuk akaun dengan pelan GitHub Percuma, repositori mestilah awam.

Setelah repositori siap, anda perlu tentukan asal usul penerbitanGitHub membolehkan anda menggunakan cawangan (contohnya, halaman utama atau gh) dan secara pilihan folder di dalamnya (seperti /docs), atau aliran kerja GitHub Actions tersuai yang menjana dan menerbitkan tapak tersebut.

Tapak ini dibina daripada fail input: biasanya a index.html, index.md o README.mdIa mesti berada di peringkat atas laluan yang telah diisytiharkan sebagai sumber (contohnya, dalam /docs (jika folder itu telah dipilih). Apabila menggunakan aliran kerja Tindakan, artifak yang diterbitkan mesti memasukkan fail tersebut dalam rootnya.

Secara lalai, jika sumber penerbitan ialah cabang, GitHub Pages akan mengkompilasi tapak tersebut dengan Jekyll. Jika anda lebih suka penjana statik yang berbeza atau proses binaan anda sendiri, anda boleh melumpuhkan Jekyll dengan mencipta fail kosong yang dipanggil .nojekyll dalam akar sumber penerbitan dan menjana fail statik itu sendiri, sama ada secara setempat atau menggunakan Tindakan.

GitHub Pages menerbitkan sebarang fail statik yang anda muat naik ke repositori: HTML, CSS, JavaScript, imej, PDF, dll. Perkhidmatan ini mengurus lebih 750 jenis MIME, berdasarkan projek mime-db. Anda tidak boleh mengkonfigurasi jenis MIME tersuai setiap repositori, tetapi anda boleh menyumbang kepada mime-db jika anda perlu mengembangkan senarai global.

Untuk melihat laman web yang diterbitkan, sila pergi ke tab Tetapan → Halaman daripada repositori dan ikuti pautan Lawati tapak. Jika anda telah mencipta, sebagai contoh, fail /about/contact-us.md dalam cabang penerbitan, ia akan berfungsi sebagai /about/contact-us.html dalam URL akhir projek.

Susun kod infrastruktur dan kod aplikasi pada GitHub

Satu persoalan yang sangat lazim ialah bagaimana untuk mengatur repositori atau repositori-repositori apabila bekerja dengan Terraform, CloudFormation atau alatan IaC lain bersama-sama kod aplikasi. Ini melibatkan keputusan seni bina repositori (repo tunggal vs. berbilang repo) dan strategi penggunaan.

Sesetengah pasukan memilih repositori monolitik (monorepo) di mana kod aplikasi dan infrastruktur wujud bersama. Kelebihan: semuanya bersama, perubahan aplikasi dan infrastruktur yang diselaraskan disemak dalam permintaan tarik yang sama dan saluran paip boleh dicetuskan untuk mengesahkan kedua-duanya secara serentak. Adalah perkara biasa bagi cabang pembangunan untuk mencetuskan penggunaan automatik untuk menguji persekitaran.

Ada juga yang lebih suka memisahkan infrastruktur dan aplikasi ke dalam repositori yang berbeza . Dalam model ini, repositori IaC memberi tumpuan kepada rangkaian, pangkalan data, barisan, kebenaran dan sebagainya, manakala repositori aplikasi mengurus kod perniagaan. Pelaksanaan juga diatur secara berasingan, yang boleh memudahkan pemversian infrastruktur, penggunaan semula merentasi berbilang perkhidmatan atau mewakilkan pengurusan infrastruktur kepada pasukan yang berbeza.

Pilihannya banyak bergantung pada budaya DevOps pasukan, skala sistem dan tahap automasi saluran paip . Apabila matlamatnya adalah untuk setiap perubahan dalam cabang pembangunan mencetuskan penggunaan penuh (infrastruktur + aplikasi), repositori tunggal dengan saluran paip yang ditala dengan baik biasanya lebih disukai. Apabila infrastrukturnya kompleks, dikongsi oleh banyak aplikasi atau diuruskan oleh pasukan platform, pemisahan biasanya merupakan pilihan terbaik.

Walau apa pun pendekatannya, GitHub menyediakan alatan untuk mengawal kualiti dan keselamatan infrastruktur : semakan kod, pengesahan automatik Terraform atau CloudFormation dalam Tindakan, imbasan keselamatan, penyepaduan dengan alatan luaran dan banyak lagi. Perkara yang penting ialah infrastruktur sentiasa dianggap sebagai kod, di bawah kawalan versi dan dengan proses semakan yang jelas.

Pendidikan universiti: Projek DevOps dengan GitHub sebagai platform pusat

Dalam bidang akademik, terdapat kursus infrastruktur maya dan kejuruteraan awan yang menggunakan GitHub sebagai alat utama untuk mengajar DevOps. Contoh tipikal ialah kursus wajib pada tahun akhir Kejuruteraan Komputer (cawangan Teknologi Maklumat) dan elektif dalam cabang lain dan ijazah berganda.

Kursus ini diajar di dalam bilik darjah makmal, dengan kelas praktikal yang kebanyakannya di mana pelajar mesti membawa komputer riba untuk mengerjakan projek tersebut. Banyak sesi dirakam video dan tersedia dalam senarai main, tetapi disyorkan untuk menggunakannya terutamanya untuk konsep, bukan untuk aspek pentadbiran yang berubah setiap semester.

Projek kursus ini diuruskan sepenuhnya menggunakan repositori GitHub . Setiap pelajar menyediakan akaun pengguna mereka supaya pengajar boleh menilai penyerahan. Setiap penyerahan dipanggil "objektif" dan mewakili hasil pembelajaran yang dicapai: penggunaan alatan pembangunan, cerita dan perancangan pengguna, pemodelan, automasi tugas, ujian unit, bekas ujian, integrasi berterusan, perkhidmatan penting, REST, dsb.

Objektif tersebut mempunyai tarikh akhir dan tarikh siap yang jelas, dibahagikan mengikut minggu, dengan lajur yang menunjukkan tarikh akhir wajib dan tarikh yang disyorkan untuk mencapai gred tertinggi. Kegagalan untuk memenuhi tarikh akhir tertentu akan mengakibatkan kegagalan lulus objektif dalam tempoh peperiksaan biasa. Penilaian distrukturkan mengikut objektif yang telah diselesaikan, dengan jadual gantian untuk sebarang objektif yang hilang, dan peraturan khusus untuk tempoh peperiksaan ulangan.

Objektif keseluruhan kursus ini adalah untuk pelajar dapat menentukan masalah dan persekitaran ujiannya, menggunakannya pada PaaS, mengkonfigurasi integrasi berterusan, mencipta persekitaran maya, memahami sokongan fizikal untuk virtualisasi, mengautomasikan konfigurasi dan menggunakan semua ini untuk penggunaan awan besar-besaran. GitHub digunakan sebagai tempat semula jadi untuk mengehos kedua-dua kod aplikasi dan fail infrastruktur dan dokumentasi.

Kandungan teori dan praktikal: daripada virtualisasi kepada DevOps

Program untuk kursus ini menggabungkan topik teori dengan latihan praktikal berpandu . Bahagian IaaS memperkenalkan sejarah virtualisasi, pengasingan sumber, storan maya, pengurusan konfigurasi dan pengkomputeran tanpa pelayan, sentiasa dengan tujuan untuk aplikasinya dalam projek dunia sebenar.

Adalah disyorkan untuk merujuk bahan tambahan seperti kursus mini Markdown, pengenalan ringan kepada Git atau bahasa Ruby, yang semuanya akan memudahkan kerja dengan repositori GitHub dan alatan konfigurasi yang ditulis dalam Ruby atau yang menggunakan YAML. Tutorial disokong oleh saluran seperti Telegram atau Google Meet, yang bertujuan untuk persekitaran pembelajaran yang serupa dengan realiti persekitaran profesional yang diedarkan.

Dalam komponen amali, pelajar membangunkan projek sepanjang kursus mengikut pendekatan DevOps . Mereka bekerja dengan mesin maya (tempatan atau berasaskan awan), peruntukan dan automasi, integrasi berterusan, perkhidmatan mikro, REST dan penggunaan PaaS. Aktiviti khusus termasuk latihan main peranan untuk membangunkan empati pelanggan, latihan penilaian kendiri dan pengujian dengan kontena dan perkhidmatan awan demo.

Projek-projek terdahulu merangkumi latihan dalam virtualisasi aplikasi, sistem tanpa pelayan, penciptaan mikroservis dan penggunaan awan dengan pelbagai versi Platform sebagai Perkhidmatan. Banyak bahan tersedia di bawah lesen terbuka dan dihoskan di GitHub, yang menggalakkan pelajar menyumbang permintaan tarik untuk penambahbaikan.

Pendek kata, GitHub bukan sahaja menjadi repositori kod, tetapi juga hab infrastruktur latihan : projek, dokumentasi, skrip penggunaan, buku panduan Ansible, resipi Chef, fail Vagrant, saluran paip CI dan semua yang diperlukan untuk mensimulasikan kerja dalam persekitaran profesional.

Infrastruktur GitHub, yang ditakrifkan secara meluas, merangkumi segala-galanya daripada cara repositori aplikasi dan infrastruktur disusun (bersama atau berasingan), kepada cara penggunaan diautomasikan dengan Actions, laman web diterbitkan dengan GitHub Pages, aplikasi dimodenkan dalam Azure dengan ejen Copilot dan semua ini diajar di universiti. Dengan menganggap infrastruktur sebagai kod, memusatkannya pada GitHub dan memanfaatkan alatan seperti Terraform, Ansible, Chef, Vagrant atau perkhidmatan platform itu sendiri, adalah mungkin untuk membina sistem yang lebih boleh dihasilkan semula, selamat dan boleh diskala, baik dalam projek dunia sebenar mahupun persekitaran pembelajaran.

Artikel berkaitan:

Cara menyediakan aliran kerja CI/CD dengan Tindakan GitHub dari awal

Ishak

Penulis yang bersemangat tentang dunia bait dan teknologi secara umum. Saya suka berkongsi pengetahuan saya melalui penulisan, dan itulah yang akan saya lakukan dalam blog ini, menunjukkan kepada anda semua perkara yang paling menarik tentang alat, perisian, perkakasan, trend teknologi dan banyak lagi. Matlamat saya adalah untuk membantu anda mengemudi dunia digital dengan cara yang mudah dan menghiburkan.