{"id":87282,"date":"2020-07-06T13:44:51","date_gmt":"2020-07-06T11:44:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury"},"modified":"2021-02-01T11:41:48","modified_gmt":"2021-02-01T09:41:48","slug":"ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/ot-startapa-do-tysyach-serverov-v-desyatke-czod-kak-my-gnalis-za-rostom-linux-infrastruktury","title":{"rendered":"Fr\u00e5n \"startup\" till tusentals servrar i ett dussin datacenter. Hur vi jagade tillv\u00e4xten av Linux-infrastrukturen","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Om din IT-infrastruktur v\u00e4xer f\u00f6r snabbt, kommer du f\u00f6rr eller senare att st\u00e5 inf\u00f6r valet \u2013 att linj\u00e4rt \u00f6ka personalresurserna f\u00f6r att st\u00f6dja den, eller att b\u00f6rja automatisera. Fram till en viss punkt levde vi i den f\u00f6rsta paradigmen, och sedan b\u00f6rjade den l\u00e5nga v\u00e4gen mot Infrastructure-as-Code.<\/p>\n

\"Fr\u00e5n
\n<\/a><\/noindex>
\nSj\u00e4lvklart \u00e4r NSPK inte en startup, men en s\u00e5dan atmosf\u00e4r r\u00e5dde i f\u00f6retaget under de f\u00f6rsta \u00e5ren, och det var mycket intressanta \u00e5r. Jag heter Dmitrij Kornev<\/a><\/noindex>, jag har i \u00f6ver 10 \u00e5r st\u00f6ttat Linux-infrastruktur med h\u00f6ga tillg\u00e4nglighetskrav. Jag gick med i NSPK i januari 2016 och fick tyv\u00e4rr inte uppleva f\u00f6retagets b\u00f6rjan, men jag kom in p\u00e5 en tid med stora f\u00f6r\u00e4ndringar.<\/p>\n

\u00d6verlag kan man s\u00e4ga att v\u00e5rt team levererar tv\u00e5 produkter f\u00f6r f\u00f6retaget. F\u00f6rsta produkten \u00e4r infrastrukturer. E-posten m\u00e5ste g\u00e5, DNS m\u00e5ste fungera, och dom\u00e4nkontrollerna m\u00e5ste sl\u00e4ppa in er p\u00e5 servrar som inte f\u00e5r falla. F\u00f6retagets IT-landskap \u00e4r enormt! Detta \u00e4r aff\u00e4rs- och mission-critical system, vissa har tillg\u00e4nglighetskrav p\u00e5 99,999. Den andra produkten \u00e4r sj\u00e4lva servrarna, b\u00e5de fysiska och virtuella. De befintliga m\u00e5ste \u00f6vervakas och nya m\u00e5ste regelbundet levereras till kunder fr\u00e5n m\u00e5nga avdelningar. I den h\u00e4r artikeln vill jag fokusera p\u00e5 hur vi utvecklade infrastrukturen som ansvarar f\u00f6r livscykeln servrar<\/a>.<\/p>\n

Framstegens b\u00f6rjan<\/b><\/p>\n

I b\u00f6rjan av v\u00e5r resa s\u00e5g v\u00e5r teknikstack ut s\u00e5 h\u00e4r:
\nOS CentOS 7
\nDom\u00e4nkontroller FreeIPA
\nAutomatisering \u2013 Ansible(+Tower), Cobbler<\/i><\/p>\n

Allt detta var f\u00f6rdelat p\u00e5 3 dom\u00e4ner, spridda \u00f6ver flera datacenter. I ett datacenter fanns kontorssystem och testmilj\u00f6er, i de andra PROD.<\/p>\n

Skapandet av servrar s\u00e5g vid n\u00e5got tillf\u00e4lle ut s\u00e5 h\u00e4r:<\/p>\n

\"Fr\u00e5n<\/p>\n

I mallen f\u00f6r VM CentOS minimal och den n\u00f6dv\u00e4ndiga minimigr\u00e4nsen som en korrekt \/etc\/resolv.conf, resten kommer via Ansible.<\/p>\n

CMDB \u2013 Excel.<\/p>\n

Om servern \u00e4r fysisk, installeras operativsystemet direkt ist\u00e4llet f\u00f6r att kopiera en virtuell maskin till den, med hj\u00e4lp av Cobbler \u2013 MAC-adresserna f\u00f6r den m\u00e5lservern l\u00e4ggs till i Cobbler-konfigurationen, servern f\u00e5r IP-adress via DHCP, och sedan installeras operativsystemet.<\/p>\n

I b\u00f6rjan f\u00f6rs\u00f6kte vi till och med g\u00f6ra n\u00e5gon slags configuration management i Cobbler. Men med tiden b\u00f6rjade det orsaka problem med portabilitet av konfigurationer b\u00e5de till andra datacenter och i Ansible-kod f\u00f6r att f\u00f6rbereda VM.<\/p>\n

M\u00e5nga av oss uppfattade Ansible som en bekv\u00e4m utvidgning av Bash och var inte f\u00f6rsiktiga med att anv\u00e4nda konstruktioner med shell, sed. I stort sett var det Bashsible. Detta ledde till att om en playbook av n\u00e5gon anledning inte fungerade p\u00e5 servern, var det enklare att ta bort servern, justera playbooken och k\u00f6ra om. Det fanns i praktiken ingen versionering av skripten, inte heller n\u00e5gon b\u00e4rbarhet i konfigurationerna.<\/p>\n

Till exempel ville vi \u00e4ndra en konfiguration p\u00e5 alla servrar:<\/p>\n

    \n
  1. \u00c4ndrar konfigurationen p\u00e5 befintliga servrar i den logiska segmentet\/datacentret. Ibland inte p\u00e5 en dag \u2013 tillg\u00e5ngskrav och storhetens lag till\u00e5ter inte att alla \u00e4ndringar till\u00e4mpas p\u00e5 en g\u00e5ng. Vissa \u00e4ndringar kan potentiellt vara destruktiva och kr\u00e4ver omstart av n\u00e5got \u2013 fr\u00e5n tj\u00e4nster till sj\u00e4lva operativsystemet.<\/li>\n
  2. Fixar i Ansible<\/li>\n
  3. Fixar i Cobbler<\/li>\n
  4. Upprepa N g\u00e5nger f\u00f6r varje logiskt segment\/datacenter<\/li>\n<\/ol>\n

    F\u00f6r att alla \u00e4ndringar ska g\u00e5 smidigt m\u00e5ste man ta h\u00e4nsyn till m\u00e5nga faktorer, och \u00e4ndringar sker hela tiden.<\/p>\n