ໃກ້ຮອດປີໃໝ່ແລ້ວ. ເດັກນ້ອຍໃນທົ່ວປະເທດໄດ້ສົ່ງຈົດຫມາຍໄປຫາ Santa Claus ຫຼືເຮັດຂອງຂວັນສໍາລັບຕົນເອງ, ແລະຜູ້ປະຕິບັດການຕົ້ນຕໍຂອງພວກເຂົາ, ຫນຶ່ງໃນຮ້ານຂາຍຍ່ອຍທີ່ສໍາຄັນ, ກໍາລັງກະກຽມສໍາລັບການ apotheosis ຂອງການຂາຍ. ໃນເດືອນທັນວາ, ການໂຫຼດຢູ່ໃນສູນຂໍ້ມູນຂອງມັນເພີ່ມຂຶ້ນຫຼາຍຄັ້ງ. ດັ່ງນັ້ນ, ບໍລິສັດໄດ້ຕັດສິນໃຈປັບປຸງສູນຂໍ້ມູນໃຫ້ທັນສະ ໄໝ ແລະ ນຳ ໃຊ້ເຄື່ອງແມ່ຂ່າຍ ໃໝ່ ຫຼາຍ ໜ່ວຍ ແທນທີ່ຈະເປັນອຸປະກອນທີ່ມາຮອດທ້າຍຂອງຊີວິດການບໍລິການ. ເລື່ອງນີ້ສິ້ນສຸດການເລົ່າເລື່ອງຕໍ່ກັບພື້ນຫລັງຂອງກ້ອນຫິມະທີ່ໝູນວຽນມາ, ແລະຄວາມຕື່ນເຕັ້ນກໍ່ເລີ່ມຂຶ້ນ.

ອຸປະກອນດັ່ງກ່າວມາຮອດສະຖານທີ່ຫຼາຍເດືອນກ່ອນທີ່ຈະມີຍອດຂາຍສູງສຸດ. ການບໍລິການປະຕິບັດງານ, ແນ່ນອນ, ຮູ້ຈັກວິທີແລະສິ່ງທີ່ຈະ configure ໃນເຄື່ອງແມ່ຂ່າຍເພື່ອນໍາພວກເຂົາເຂົ້າໄປໃນສະພາບແວດລ້ອມການຜະລິດ. ແຕ່ພວກເຮົາຕ້ອງການອັດຕະໂນມັດນີ້ແລະລົບລ້າງປັດໄຈຂອງມະນຸດ. ນອກຈາກນັ້ນ, ເຄື່ອງແມ່ຂ່າຍໄດ້ຖືກປ່ຽນແທນກ່ອນການເຄື່ອນຍ້າຍຂອງຊຸດຂອງລະບົບ SAP ທີ່ສໍາຄັນສໍາລັບບໍລິສັດ.

ການມອບໝາຍຂອງເຊີບເວີໃໝ່ຖືກຜູກມັດຢ່າງເຂັ້ມງວດກັບເສັ້ນຕາຍ. ​ແລະ​ການ​ເຄື່ອນ​ຍ້າຍ​ນັ້ນ​ໝາຍ​ຄວາມ​ວ່າ​ຈະ​ເປັນ​ອັນຕະລາຍ​ຕໍ່​ການ​ສົ່ງ​ຂອງ​ຂວັນ​ນັບ​ພັນ​ລ້ານ​ອັນ ​ແລະ​ການ​ເຄື່ອນ​ຍ້າຍ​ຂອງ​ລະບົບ. ເຖິງແມ່ນວ່າທີມງານທີ່ປະກອບດ້ວຍພຣະບິດາ Frost ແລະ Santa Claus ບໍ່ສາມາດປ່ຽນວັນທີ - ທ່ານສາມາດໂອນລະບົບ SAP ສໍາລັບການຄຸ້ມຄອງສາງໄດ້ພຽງແຕ່ຫນຶ່ງຄັ້ງຕໍ່ປີ. ແຕ່ວັນທີ 31 ເດືອນທັນວາຫາວັນທີ 1 ມັງກອນ, ຄັງສິນຄ້າຂະຫນາດໃຫຍ່ຂອງຮ້ານຂາຍຍ່ອຍ, ໃນຈໍານວນທັງຫມົດ 20 ກິລາບານເຕະ, ຢຸດເຊົາການເຮັດວຽກຂອງພວກເຂົາເປັນເວລາ 15 ຊົ່ວໂມງ. ແລະນີ້ແມ່ນໄລຍະເວລາພຽງແຕ່ສໍາລັບການເຄື່ອນຍ້າຍລະບົບ. ພວກເຮົາບໍ່ມີບ່ອນຫວ່າງສຳລັບຄວາມຜິດພາດໃນເວລາແນະນຳເຊີບເວີ.

ໃຫ້ຂ້ອຍຈະແຈ້ງ: ເລື່ອງຂອງຂ້ອຍສະທ້ອນໃຫ້ເຫັນເຖິງເຄື່ອງມືແລະຂະບວນການຈັດການການຕັ້ງຄ່າທີ່ທີມງານຂອງພວກເຮົາໃຊ້.

ສະລັບສັບຊ້ອນການຈັດການການຕັ້ງຄ່າປະກອບດ້ວຍຫຼາຍລະດັບ. ອົງປະກອບທີ່ສໍາຄັນແມ່ນລະບົບ CMS. ໃນການດໍາເນີນງານອຸດສາຫະກໍາ, ການຂາດລະດັບຫນຶ່ງຈະນໍາໄປສູ່ການມະຫັດສະຈັນທີ່ບໍ່ຫນ້າພໍໃຈ.

ການຄຸ້ມຄອງການຕິດຕັ້ງ OS

ລະດັບທໍາອິດແມ່ນລະບົບການຄຸ້ມຄອງການຕິດຕັ້ງລະບົບປະຕິບັດການໃນເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍແລະ virtual. ມັນສ້າງການຕັ້ງຄ່າ OS ພື້ນຖານ, ກໍາຈັດປັດໃຈຂອງມະນຸດ.

ການນໍາໃຊ້ລະບົບນີ້, ພວກເຮົາໄດ້ຮັບຕົວຢ່າງຂອງເຄື່ອງແມ່ຂ່າຍມາດຕະຖານທີ່ມີ OS ທີ່ເຫມາະສົມສໍາລັບອັດຕະໂນມັດຕື່ມອີກ. ໃນລະຫວ່າງການ "ຖອກເທ" ພວກເຂົາໄດ້ຮັບຊຸດຕໍາ່ສຸດທີ່ຂອງຜູ້ໃຊ້ທ້ອງຖິ່ນແລະກະແຈ SSH ສາທາລະນະ, ເຊັ່ນດຽວກັນກັບການຕັ້ງຄ່າ OS ທີ່ສອດຄ່ອງ. ພວກເຮົາສາມາດຮັບປະກັນການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍຜ່ານ CMS ແລະແນ່ໃຈວ່າບໍ່ມີຄວາມແປກໃຈ "ຕ່ໍາກວ່າ" ໃນລະດັບ OS.

ວຽກງານ "ສູງສຸດ" ສໍາລັບລະບົບການຄຸ້ມຄອງການຕິດຕັ້ງແມ່ນການຕັ້ງຄ່າເຄື່ອງແມ່ຂ່າຍອັດຕະໂນມັດຈາກລະດັບ BIOS / Firmware ໄປຫາ OS. ສ່ວນຫຼາຍໃນທີ່ນີ້ແມ່ນຂຶ້ນກັບອຸປະກອນແລະວຽກງານການຕິດຕັ້ງ. ສໍາລັບອຸປະກອນ heterogeneous, ທ່ານສາມາດພິຈາລະນາ REDFISH API. ຖ້າຮາດແວທັງຫມົດມາຈາກຜູ້ຂາຍຫນຶ່ງ, ມັນມັກຈະສະດວກກວ່າທີ່ຈະໃຊ້ເຄື່ອງມືການຈັດການທີ່ກຽມພ້ອມ (ຕົວຢ່າງເຊັ່ນ HP ILO Amplifier, DELL OpenManage, ແລະອື່ນໆ).

ເພື່ອຕິດຕັ້ງ OS ໃນເຊີບເວີທາງກາຍະພາບ, ພວກເຮົາໄດ້ໃຊ້ Cobbler ທີ່ມີຊື່ສຽງ, ເຊິ່ງກໍານົດຊຸດຂອງໂປໄຟການຕິດຕັ້ງທີ່ຕົກລົງກັບການບໍລິການປະຕິບັດງານ. ເມື່ອເພີ່ມເຄື່ອງແມ່ຂ່າຍໃຫມ່ໃສ່ໂຄງສ້າງພື້ນຖານ, ວິສະວະກອນໄດ້ຜູກມັດທີ່ຢູ່ MAC ຂອງເຄື່ອງແມ່ຂ່າຍກັບໂປຣໄຟລ໌ທີ່ຕ້ອງການໃນ Cobbler. ເມື່ອ booting ຜ່ານເຄືອຂ່າຍເປັນຄັ້ງທໍາອິດ, ເຄື່ອງແມ່ຂ່າຍໄດ້ຮັບທີ່ຢູ່ຊົ່ວຄາວແລະ OS ສົດ. ຫຼັງຈາກນັ້ນ, ມັນຖືກໂອນໄປຫາທີ່ຢູ່ VLAN / IP ເປົ້າຫມາຍແລະສືບຕໍ່ເຮັດວຽກຢູ່ທີ່ນັ້ນ. ແມ່ນແລ້ວ, ການປ່ຽນແປງ VLAN ໃຊ້ເວລາແລະຕ້ອງການການປະສານງານ, ແຕ່ມັນສະຫນອງການປົກປ້ອງເພີ່ມເຕີມຕໍ່ກັບການຕິດຕັ້ງເຄື່ອງແມ່ຂ່າຍໂດຍບັງເອີນໃນສະພາບແວດລ້ອມການຜະລິດ.

ພວກເຮົາສ້າງເຊີບເວີ virtual ໂດຍອີງໃສ່ແມ່ແບບທີ່ກະກຽມໂດຍໃຊ້ Hashiї Packer. ເຫດຜົນແມ່ນຄືກັນ: ເພື່ອປ້ອງກັນຄວາມຜິດພາດຂອງມະນຸດໃນເວລາທີ່ຕິດຕັ້ງ OS. ແຕ່, ບໍ່ເຫມືອນກັບເຄື່ອງແມ່ຂ່າຍທາງດ້ານຮ່າງກາຍ, Packer ກໍາຈັດຄວາມຕ້ອງການສໍາລັບ PXE, ການບູດເຄືອຂ່າຍ, ແລະການປ່ຽນແປງ VLAN. ນີ້ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນແລະງ່າຍດາຍໃນການສ້າງເຄື່ອງແມ່ຂ່າຍ virtual.

ເຂົ້າ. 1. ການຄຸ້ມຄອງການຕິດຕັ້ງລະບົບປະຕິບັດການ.

ການຄຸ້ມຄອງຄວາມລັບ

ລະບົບການຈັດການການຕັ້ງຄ່າໃດນຶ່ງມີຂໍ້ມູນທີ່ຄວນຈະຖືກເຊື່ອງໄວ້ຈາກຜູ້ໃຊ້ທົ່ວໄປ, ແຕ່ມີຄວາມຈໍາເປັນໃນການກະກຽມລະບົບ. ເຫຼົ່ານີ້ແມ່ນລະຫັດຜ່ານສໍາລັບຜູ້ໃຊ້ທ້ອງຖິ່ນແລະບັນຊີບໍລິການ, ກະແຈໃບຢັ້ງຢືນ, API Tokens ຕ່າງໆ, ແລະອື່ນໆ. ປົກກະຕິແລ້ວພວກມັນເອີ້ນວ່າ "ຄວາມລັບ".

ຖ້າທ່ານບໍ່ໄດ້ກໍານົດໃນຕອນຕົ້ນວ່າບ່ອນໃດແລະວິທີການເກັບຮັກສາຄວາມລັບເຫຼົ່ານີ້, ຫຼັງຈາກນັ້ນ, ອີງຕາມຄວາມຮ້າຍແຮງຂອງຄວາມຕ້ອງການຄວາມປອດໄພຂອງຂໍ້ມູນ, ວິທີການເກັບຮັກສາຕໍ່ໄປນີ້ແມ່ນເປັນໄປໄດ້:

• ໂດຍກົງໃນລະຫັດການຄວບຄຸມການຕັ້ງຄ່າຫຼືໃນໄຟລ໌ໃນ repository;
• ໃນເຄື່ອງມືການຄຸ້ມຄອງການຕັ້ງຄ່າພິເສດ (ຕົວຢ່າງ, Ansible Vault);
• ໃນລະບົບ CI/CD (Jenkins/TeamCity/GitLab/etc.) ຫຼືໃນລະບົບການຈັດການການຕັ້ງຄ່າ (Ansible Tower/Ansible AWX);
• ຄວາມລັບຍັງສາມາດຖືກໂອນ "ດ້ວຍຕົນເອງ". ຕົວຢ່າງ, ພວກມັນຖືກວາງໄວ້ໃນສະຖານທີ່ທີ່ກໍານົດໄວ້, ແລະຫຼັງຈາກນັ້ນພວກມັນຖືກນໍາໃຊ້ໂດຍລະບົບການຄຸ້ມຄອງການຕັ້ງຄ່າ;
• ການປະສົມປະສານຕ່າງໆຂອງຂ້າງເທິງ.

ແຕ່ລະວິທີມີຂໍ້ເສຍຂອງຕົນເອງ. ສິ່ງທີ່ສໍາຄັນແມ່ນການຂາດນະໂຍບາຍສໍາລັບການເຂົ້າເຖິງຄວາມລັບ: ມັນເປັນໄປບໍ່ໄດ້ຫຼືຍາກທີ່ຈະກໍານົດຜູ້ທີ່ສາມາດນໍາໃຊ້ຄວາມລັບບາງຢ່າງ. ຂໍ້ເສຍອີກອັນຫນຶ່ງແມ່ນການຂາດການກວດສອບການເຂົ້າເຖິງແລະວົງຈອນຊີວິດຢ່າງເຕັມທີ່. ວິທີການທົດແທນຢ່າງໄວວາ, ຕົວຢ່າງ, ລະຫັດສາທາລະນະທີ່ຖືກຂຽນໄວ້ໃນລະຫັດແລະລະບົບທີ່ກ່ຽວຂ້ອງຈໍານວນຫນຶ່ງ?

ພວກ​ເຮົາ​ໄດ້​ນໍາ​ໃຊ້​ການ​ເກັບ​ຮັກ​ສາ​ຄວາມ​ລັບ​ສູນ​ກາງ HashiCorp Vault​. ນີ້ອະນຸຍາດໃຫ້ພວກເຮົາ:

• ຮັກສາຄວາມລັບໃຫ້ປອດໄພ. ພວກມັນຖືກເຂົ້າລະຫັດ, ແລະເຖິງແມ່ນວ່າຜູ້ໃດຜູ້ຫນຶ່ງໄດ້ຮັບການເຂົ້າເຖິງຖານຂໍ້ມູນ Vault (ຕົວຢ່າງເຊັ່ນ, ໂດຍການຟື້ນຟູມັນຈາກການສໍາຮອງຂໍ້ມູນ), ພວກເຂົາຈະບໍ່ສາມາດອ່ານຄວາມລັບທີ່ເກັບໄວ້ໃນບ່ອນນັ້ນ;
• ຈັດຕັ້ງນະໂຍບາຍເພື່ອເຂົ້າເຖິງຄວາມລັບ. ພຽງແຕ່ຄວາມລັບທີ່ "ຈັດສັນ" ໃຫ້ພວກເຂົາມີໃຫ້ກັບຜູ້ໃຊ້ແລະແອັບພລິເຄຊັນ;
• ການກວດສອບການເຂົ້າເຖິງຄວາມລັບ. ການກະທໍາໃດໆທີ່ມີຄວາມລັບຖືກບັນທຶກໄວ້ໃນບັນທຶກການກວດສອບ Vault;
• ຈັດຕັ້ງ "ວົງຈອນຊີວິດ" ເຕັມຮູບແບບຂອງການເຮັດວຽກກັບຄວາມລັບ. ພວກເຂົາສາມາດສ້າງ, ຖອນຄືນ, ກໍານົດວັນຫມົດອາຍຸ, ແລະອື່ນໆ.
• ງ່າຍທີ່ຈະປະສົມປະສານກັບລະບົບອື່ນໆທີ່ຕ້ອງການການເຂົ້າເຖິງຄວາມລັບ;
• ແລະຍັງໃຊ້ການເຂົ້າລະຫັດແບບ end-to-end, ລະຫັດຜ່ານຄັ້ງດຽວສໍາລັບ OS ແລະຖານຂໍ້ມູນ, ໃບຢັ້ງຢືນຂອງສູນທີ່ໄດ້ຮັບອະນຸຍາດ, ແລະອື່ນໆ.

ຕອນນີ້ໃຫ້ເຮົາກ້າວໄປສູ່ລະບົບການຢັ້ງຢືນແລະການອະນຸຍາດສູນກາງ. ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໂດຍບໍ່ມີມັນ, ແຕ່ການຄຸ້ມຄອງຜູ້ໃຊ້ໃນຫຼາຍໆລະບົບທີ່ກ່ຽວຂ້ອງແມ່ນບໍ່ເປັນເລື່ອງເລັກນ້ອຍ. ພວກເຮົາໄດ້ຕັ້ງຄ່າການຮັບຮອງຄວາມຖືກຕ້ອງ ແລະອະນຸຍາດຜ່ານການບໍລິການ LDAP. ຖ້າບໍ່ດັ່ງນັ້ນ, Vault ຈະຕ້ອງອອກຢ່າງຕໍ່ເນື່ອງ ແລະຕິດຕາມ tokens ການກວດສອບຄວາມຖືກຕ້ອງສໍາລັບຜູ້ໃຊ້. ແລະການລຶບແລະເພີ່ມຜູ້ໃຊ້ຈະປ່ຽນເປັນການຄົ້ນຫາ "ຂ້ອຍໄດ້ສ້າງ / ລຶບບັນຊີຜູ້ໃຊ້ນີ້ຢູ່ທົ່ວທຸກແຫ່ງບໍ?"

ພວກ​ເຮົາ​ເພີ່ມ​ອີກ​ລະ​ດັບ​ຫນຶ່ງ​ໃນ​ລະ​ບົບ​ຂອງ​ພວກ​ເຮົາ​: ການ​ຄຸ້ມ​ຄອງ​ຄວາມ​ລັບ​ແລະ​ການ​ກວດ​ສອບ​ສູນ​ກາງ / ການ​ອະ​ນຸ​ຍາດ​:

ເຂົ້າ. 2. ການຄຸ້ມຄອງຄວາມລັບ.

ການຈັດການການຕັ້ງຄ່າ

ພວກເຮົາມາຮອດຫຼັກ - ລະບົບ CMS. ໃນກໍລະນີຂອງພວກເຮົາ, ນີ້ແມ່ນການປະສົມປະສານຂອງ Ansible ແລະ Red Hat Ansible AWX.

ແທນທີ່ຈະເປັນ Ansible, Chef, Puppet, SaltStack ສາມາດນໍາໃຊ້ໄດ້. ພວກເຮົາເລືອກ Ansible ໂດຍອີງໃສ່ເງື່ອນໄຂຈໍານວນຫນຶ່ງ.

• ປະການທໍາອິດ, ມັນເປັນ versatility. ຊຸດຂອງໂມດູນທີ່ກຽມພ້ອມສໍາລັບການຄວບຄຸມ ມັນປະທັບໃຈ. ແລະຖ້າທ່ານບໍ່ມີມັນພຽງພໍ, ທ່ານສາມາດຄົ້ນຫາໃນ GitHub ແລະ Galaxy.
• ອັນທີສອງ, ບໍ່ຈໍາເປັນຕ້ອງຕິດຕັ້ງແລະສະຫນັບສະຫນູນຕົວແທນກ່ຽວກັບອຸປະກອນທີ່ມີການຄຸ້ມຄອງ, ພິສູດວ່າພວກເຂົາບໍ່ແຊກແຊງການໂຫຼດ, ແລະຢືນຢັນການບໍ່ມີ "bookmarks".
• ອັນທີສາມ, Ansible ມີອຸປະສັກຕໍ່າຕໍ່ການເຂົ້າ. ວິສະວະກອນທີ່ມີຄວາມສາມາດຈະຂຽນປື້ມບັນທຶກການເຮັດວຽກທີ່ຮູ້ຫນັງສືໃນມື້ທໍາອິດຂອງການເຮັດວຽກກັບຜະລິດຕະພັນ.

ແຕ່ Ansible ດຽວໃນສະພາບແວດລ້ອມການຜະລິດແມ່ນບໍ່ພຽງພໍສໍາລັບພວກເຮົາ. ຖ້າບໍ່ດັ່ງນັ້ນ, ບັນຫາຫຼາຍຢ່າງຈະເກີດຂື້ນກັບການຈໍາກັດການເຂົ້າເຖິງແລະການກວດສອບການປະຕິບັດຂອງຜູ້ບໍລິຫານ. ວິທີການຈໍາກັດການເຂົ້າເຖິງ? ຫຼັງຈາກທີ່ທັງຫມົດ, ມັນເປັນສິ່ງຈໍາເປັນສໍາລັບແຕ່ລະພະແນກໃນການຄຸ້ມຄອງ (ອ່ານ: ດໍາເນີນການ Ansible playbook) "ຂອງຕົນເອງ" ຊຸດຂອງເຄື່ອງແມ່ຂ່າຍ. ວິທີການອະນຸຍາດໃຫ້ພະນັກງານສະເພາະເຮັດວຽກ Ansible playbooks ສະເພາະ? ຫຼືວິທີການຕິດຕາມຜູ້ທີ່ເປີດຕົວ playbook ໂດຍບໍ່ມີການກໍານົດຄວາມຮູ້ທ້ອງຖິ່ນຫຼາຍກ່ຽວກັບເຄື່ອງແມ່ຂ່າຍແລະອຸປະກອນທີ່ແລ່ນ Ansible?

ສ່ວນແບ່ງຂອງຊ້າງຂອງບັນຫາດັ່ງກ່າວໄດ້ຖືກແກ້ໄຂໂດຍ Red Hat ຫໍຄອຍ Ansible, ຫຼືໂຄງການແຫຼ່ງແຫຼ່ງເປີດຂອງລາວ Ansible AWX. ນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາມັກມັນສໍາລັບລູກຄ້າ.

ແລະອີກອັນຫນຶ່ງສໍາຜັດກັບຮູບຄົນຂອງລະບົບ CMS ຂອງພວກເຮົາ. Ansible playbook ຄວນຖືກເກັບໄວ້ໃນລະບົບການຈັດການລະຫັດ repository. ພວກເຮົາມີມັນ GitLab CE.

ດັ່ງນັ້ນ, ການຕັ້ງຄ່າດ້ວຍຕົນເອງແມ່ນຄຸ້ມຄອງໂດຍການລວມກັນຂອງ Ansible/Ansible AWX/GitLab (ເບິ່ງຮູບ 3). ແນ່ນອນ, AWX/GitLab ແມ່ນປະສົມປະສານກັບລະບົບການພິສູດຢືນຢັນອັນດຽວ, ແລະ Ansible playbook ແມ່ນປະສົມປະສານກັບ HashiCorp Vault. ການຕັ້ງຄ່າເຂົ້າໄປໃນສະພາບແວດລ້ອມການຜະລິດຜ່ານ Ansible AWX ເທົ່ານັ້ນ, ເຊິ່ງທຸກ "ກົດລະບຽບຂອງເກມ" ໄດ້ຖືກລະບຸໄວ້: ໃຜສາມາດກໍານົດສິ່ງທີ່, ບ່ອນທີ່ໄດ້ຮັບລະຫັດການຄຸ້ມຄອງການຕັ້ງຄ່າສໍາລັບ CMS, ແລະອື່ນໆ.

ເຂົ້າ. 3. ການຈັດການການຕັ້ງຄ່າ.

ການ​ຄຸ້ມ​ຄອງ​ການ​ທົດ​ສອບ​

ການຕັ້ງຄ່າຂອງພວກເຮົາຖືກນໍາສະເຫນີໃນຮູບແບບລະຫັດ. ດັ່ງນັ້ນ, ພວກເຮົາຖືກບັງຄັບໃຫ້ຫຼິ້ນໂດຍກົດລະບຽບດຽວກັນກັບນັກພັດທະນາຊອບແວ. ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຈັດຕັ້ງຂະບວນການພັດທະນາ, ການທົດສອບຢ່າງຕໍ່ເນື່ອງ, ການຈັດສົ່ງແລະການນໍາໃຊ້ລະຫັດການຕັ້ງຄ່າກັບເຄື່ອງແມ່ຂ່າຍການຜະລິດ.

ຖ້າສິ່ງນີ້ບໍ່ຖືກເຮັດໃນທັນທີ, ພາລະບົດບາດທີ່ຂຽນໄວ້ສໍາລັບການຕັ້ງຄ່າຈະຢຸດສະຫນັບສະຫນຸນແລະດັດແກ້, ຫຼືຈະຢຸດການຜະລິດ. ການປິ່ນປົວສໍາລັບຄວາມເຈັບປວດນີ້ແມ່ນເປັນທີ່ຮູ້ຈັກ, ແລະມັນໄດ້ພິສູດຕົວເອງໃນໂຄງການນີ້:

• ແຕ່ລະພາລະບົດບາດແມ່ນກວມເອົາໂດຍການທົດສອບຫນ່ວຍງານ;
• ການທົດສອບແມ່ນດໍາເນີນການໂດຍອັດຕະໂນມັດທຸກຄັ້ງທີ່ມີການປ່ຽນແປງລະຫັດທີ່ຈັດການການຕັ້ງຄ່າ;
• ການປ່ຽນແປງລະຫັດການຄຸ້ມຄອງການຕັ້ງຄ່າຖືກປ່ອຍອອກມາໃນສະພາບແວດລ້ອມການຜະລິດພຽງແຕ່ຫຼັງຈາກສໍາເລັດການທົດສອບທັງຫມົດແລະການທົບທວນຄືນລະຫັດ.

ການພັດທະນາລະຫັດແລະການຄຸ້ມຄອງການຕັ້ງຄ່າໄດ້ກາຍເປັນສະຫງົບແລະຄາດເດົາໄດ້ຫຼາຍຂຶ້ນ. ເພື່ອຈັດຕັ້ງການທົດສອບຢ່າງຕໍ່ເນື່ອງ, ພວກເຮົາໄດ້ໃຊ້ຊຸດເຄື່ອງມື GitLab CI/CD, ແລະໄດ້ເອົາ ໂມເລກຸນ Ansible.

ເມື່ອໃດກໍ່ຕາມມີການປ່ຽນແປງລະຫັດການຈັດການການຕັ້ງຄ່າ, GitLab CI/CD ໂທຫາ Molecule:

• ມັນກວດເບິ່ງ syntax ຂອງລະຫັດ,
• ຍົກຕູ້ຄອນເທນເນີ Docker,
• ນຳ​ໃຊ້​ລະ​ຫັດ​ທີ່​ດັດ​ແກ້​ໃສ່​ກັບ​ຖັງ​ທີ່​ສ້າງ​ຂຶ້ນ​,
• ກວດເບິ່ງບົດບາດສໍາລັບ ideempotency ແລະດໍາເນີນການທົດສອບສໍາລັບລະຫັດນີ້ ( granularity ນີ້ແມ່ນຢູ່ໃນລະດັບບົດບາດ ansible, ເບິ່ງຮູບ 4).

ພວກເຮົາໄດ້ສົ່ງການຕັ້ງຄ່າໃຫ້ກັບສະພາບແວດລ້ອມການຜະລິດໂດຍໃຊ້ Ansible AWX. ວິສະວະກອນປະຕິບັດການໄດ້ນໍາໃຊ້ການປ່ຽນແປງການຕັ້ງຄ່າໂດຍຜ່ານແມ່ແບບທີ່ກໍານົດໄວ້ລ່ວງຫນ້າ. AWX ໄດ້ “ຮ້ອງຂໍ” ລະຫັດສະບັບຫລ້າສຸດຈາກສາຂາແມ່ບົດ GitLab ທຸກໆຄັ້ງທີ່ມັນຖືກນໍາໃຊ້. ວິທີນີ້ພວກເຮົາຍົກເວັ້ນການໃຊ້ລະຫັດທີ່ບໍ່ໄດ້ທົດສອບຫຼືລ້າສະໄຫມໃນສະພາບແວດລ້ອມການຜະລິດ. ຕາມທໍາມະຊາດ, ລະຫັດເຂົ້າໄປໃນສາຂາຕົ້ນສະບັບພຽງແຕ່ຫຼັງຈາກການທົດສອບ, ການທົບທວນຄືນແລະການອະນຸມັດ.

ເຂົ້າ. 4. ການທົດສອບອັດຕະໂນມັດຂອງບົດບາດໃນ GitLab CI/CD.

ຍັງມີບັນຫາທີ່ກ່ຽວຂ້ອງກັບການດໍາເນີນງານຂອງລະບົບການຜະລິດ. ໃນຊີວິດຈິງ, ມັນເປັນການຍາກຫຼາຍທີ່ຈະເຮັດການປ່ຽນແປງການຕັ້ງຄ່າໂດຍຜ່ານລະຫັດ CMS ຢ່າງດຽວ. ສະຖານະການສຸກເສີນເກີດຂື້ນເມື່ອວິສະວະກອນຕ້ອງປ່ຽນການຕັ້ງຄ່າ "ທີ່ນີ້ແລະຕອນນີ້", ໂດຍບໍ່ຕ້ອງລໍຖ້າການແກ້ໄຂລະຫັດ, ການທົດສອບ, ການອະນຸມັດ, ແລະອື່ນໆ.

ດັ່ງນັ້ນ, ເນື່ອງຈາກການປ່ຽນແປງຄູ່ມື, ຄວາມແຕກຕ່າງຈະປາກົດຢູ່ໃນການຕັ້ງຄ່າໃນອຸປະກອນປະເພດດຽວກັນ (ຕົວຢ່າງເຊັ່ນ, ການຕັ້ງຄ່າ sysctl ຖືກຕັ້ງຄ່າແຕກຕ່າງກັນຢູ່ໃນ HA cluster nodes). ຫຼືການຕັ້ງຄ່າຕົວຈິງໃນອຸປະກອນແຕກຕ່າງຈາກທີ່ລະບຸໄວ້ໃນລະຫັດ CMS.

ດັ່ງນັ້ນ, ນອກເຫນືອຈາກການທົດສອບຢ່າງຕໍ່ເນື່ອງ, ພວກເຮົາກວດເບິ່ງສະພາບແວດລ້ອມການຜະລິດສໍາລັບຄວາມແຕກຕ່າງຂອງການຕັ້ງຄ່າ. ພວກເຮົາເລືອກທາງເລືອກທີ່ງ່າຍດາຍທີ່ສຸດ: ແລ່ນລະຫັດການຕັ້ງຄ່າ CMS ໃນໂຫມດ "ແລ່ນແຫ້ງ", ນັ້ນແມ່ນ, ໂດຍບໍ່ມີການນໍາໃຊ້ການປ່ຽນແປງ, ແຕ່ມີການແຈ້ງເຕືອນກ່ຽວກັບຄວາມແຕກຕ່າງລະຫວ່າງການຕັ້ງຄ່າທີ່ວາງແຜນແລະຕົວຈິງ. ພວກເຮົາປະຕິບັດອັນນີ້ໂດຍການແລ່ນປື້ມຫຼິ້ນ Ansible ທັງໝົດເປັນໄລຍະໆດ້ວຍຕົວເລືອກ “—ກວດເບິ່ງ” ໃນເຊີບເວີການຜະລິດ. ໃນຖານະເປັນສະເຫມີ, Ansible AWX ແມ່ນຮັບຜິດຊອບສໍາລັບການເປີດຕົວແລະຮັກສາ playbook ໄດ້ເຖິງວັນທີ (ເບິ່ງຮູບ 5):

ເຂົ້າ. 5. ກວດສອບຄວາມແຕກຕ່າງຂອງການຕັ້ງຄ່າໃນ Ansible AWX.

ຫຼັງຈາກການກວດສອບ, AWX ຈະສົ່ງບົດລາຍງານຄວາມແຕກຕ່າງກັນໄປຫາຜູ້ບໍລິຫານ. ພວກເຂົາເຈົ້າສຶກສາການຕັ້ງຄ່າທີ່ມີບັນຫາແລະຫຼັງຈາກນັ້ນແກ້ໄຂມັນໂດຍຜ່ານ playbooks ປັບ. ນີ້ແມ່ນວິທີທີ່ພວກເຮົາຮັກສາການຕັ້ງຄ່າໃນສະພາບແວດລ້ອມການຜະລິດແລະ CMS ແມ່ນທັນສະໄຫມແລະ synchronized ສະເຫມີ. ນີ້ກໍາຈັດ "ມະຫັດສະຈັນ" ທີ່ບໍ່ຫນ້າພໍໃຈເມື່ອລະຫັດ CMS ຖືກໃຊ້ໃນເຄື່ອງແມ່ຂ່າຍ "ການຜະລິດ".

ໃນປັດຈຸບັນພວກເຮົາມີຊັ້ນການທົດສອບທີ່ສໍາຄັນປະກອບດ້ວຍ Ansible AWX / GitLab / Molecule (ຮູບ 6).

ເຂົ້າ. 6. ການຈັດການການທົດສອບ.

ຍາກ? ຂ້ອຍບໍ່ໂຕ້ຖຽງ. ແຕ່ການຈັດການການຕັ້ງຄ່າທີ່ສັບສົນດັ່ງກ່າວໄດ້ກາຍເປັນຄໍາຕອບທີ່ສົມບູນແບບສໍາລັບຄໍາຖາມຈໍານວນຫຼາຍທີ່ກ່ຽວຂ້ອງກັບອັດຕະໂນມັດຂອງການຕັ້ງຄ່າເຊີຟເວີ. ໃນປັດຈຸບັນເຄື່ອງແມ່ຂ່າຍມາດຕະຖານຂອງຜູ້ຄ້າປີກສະເຫມີມີການຕັ້ງຄ່າທີ່ກໍານົດໄວ້ຢ່າງເຂັ້ມງວດ. CMS, ບໍ່ເຫມືອນກັບວິສະວະກອນ, ຈະບໍ່ລືມທີ່ຈະເພີ່ມການຕັ້ງຄ່າທີ່ຈໍາເປັນ, ສ້າງຜູ້ໃຊ້ແລະປະຕິບັດຫຼາຍສິບຫຼືຫຼາຍຮ້ອຍການຕັ້ງຄ່າທີ່ຕ້ອງການ.

ບໍ່ມີ "ຄວາມຮູ້ລັບ" ໃນການຕັ້ງຄ່າຂອງເຄື່ອງແມ່ຂ່າຍແລະສະພາບແວດລ້ອມໃນມື້ນີ້. ລັກສະນະທີ່ຈໍາເປັນທັງຫມົດແມ່ນສະທ້ອນໃຫ້ເຫັນຢູ່ໃນ playbook. ບໍ່ມີຄວາມຄິດສ້າງສັນແລະຄໍາແນະນໍາທີ່ບໍ່ຊັດເຈນອີກຕໍ່ໄປ: "ຕິດຕັ້ງມັນຄືກັບ Oracle ປົກກະຕິ, ແຕ່ທ່ານຈໍາເປັນຕ້ອງລະບຸສອງສາມການຕັ້ງຄ່າ sysctl ແລະເພີ່ມຜູ້ໃຊ້ທີ່ມີ UID ທີ່ຕ້ອງການ. ຖາມ guys ໃນການດໍາເນີນງານ, ພວກເຂົາເຈົ້າຮູ້".

ຄວາມສາມາດໃນການກວດຫາຄວາມແຕກຕ່າງຂອງການຕັ້ງຄ່າ ແລະແກ້ໄຂພວກມັນຢ່າງຕັ້ງຫນ້າໃຫ້ຄວາມສະຫງົບຂອງຈິດໃຈ. ຖ້າບໍ່ມີລະບົບການຈັດການການຕັ້ງຄ່າ, ນີ້ມັກຈະມີລັກສະນະແຕກຕ່າງກັນ. ບັນຫາສະສົມຈົນກ່ວາມື້ຫນຶ່ງພວກເຂົາ "ຍິງ" ເຂົ້າໄປໃນການຜະລິດ. ຫຼັງ​ຈາກ​ນັ້ນ​, ການ​ພິ​ຈາ​ລະ​ນາ​ແມ່ນ​ປະ​ຕິ​ບັດ​, ການ​ຕັ້ງ​ຄ່າ​ແມ່ນ​ໄດ້​ກວດ​ສອບ​ແລະ​ແກ້​ໄຂ​. ແລະຮອບວຽນກັບຄືນມາອີກຄັ້ງ

ແລະແນ່ນອນ, ພວກເຮົາໄດ້ເລັ່ງການເປີດຕົວເຊີບເວີເຂົ້າໃນການດໍາເນີນງານຈາກຫຼາຍໆມື້ເຖິງຊົ່ວໂມງ.

ແລ້ວ, ໃນວັນປີໃໝ່ເອງ, ເມື່ອເດັກນ້ອຍໄດ້ຫໍ່ຂອງຂວັນຢ່າງເບີກບານມ່ວນຊື່ນ ແລະ ຜູ້ໃຫຍ່ໄດ້ສະແດງຄວາມປາດຖະໜາຕາມສຽງດັງ, ວິສະວະກອນຂອງພວກເຮົາໄດ້ຍ້າຍລະບົບ SAP ໄປຫາເຊີບເວີໃໝ່. ເຖິງແມ່ນວ່າ Santa Claus ຈະເວົ້າວ່າສິ່ງມະຫັດສະຈັນທີ່ດີທີ່ສຸດແມ່ນຜູ້ທີ່ກຽມພ້ອມດີ.

PS ທີມງານຂອງພວກເຮົາມັກຈະພົບກັບຄວາມຈິງທີ່ວ່າລູກຄ້າຕ້ອງການແກ້ໄຂບັນຫາການຈັດການການຕັ້ງຄ່າແບບງ່າຍໆເທົ່າທີ່ເປັນໄປໄດ້. ໂດຍຫລັກການແລ້ວ, ຄືກັບ magic - ດ້ວຍເຄື່ອງມືດຽວ. ແຕ່ໃນຊີວິດທຸກຢ່າງແມ່ນສັບສົນຫຼາຍ (ແມ່ນແລ້ວ, ລູກປືນເງິນບໍ່ໄດ້ສົ່ງອີກເທື່ອຫນຶ່ງ): ທ່ານຕ້ອງສ້າງຂະບວນການທັງຫມົດໂດຍໃຊ້ເຄື່ອງມືທີ່ສະດວກສໍາລັບທີມງານຂອງລູກຄ້າ.

ຜູ້ຂຽນ: Sergey Artemov, ສະຖາປະນິກຂອງພະແນກ ວິທີແກ້ໄຂ DevOps "ລະບົບຂໍ້ມູນຍົນ"

ແຫຼ່ງຂໍ້ມູນ: www.habr.com