Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

Si infrastructura tua IT nimis cito excrescat, citius aut serius occurreris cum electione: lineariter auges humanas facultates ad eam sustinendam vel in automationem incipis. Usque ad aliquod punctum primum paradigma viximus, deinde longam viam ad Infrastructuram-as-Code incepimus.

Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

Utique NSPK satus non est, sed talis atmosphaera primis annis regnavit in consortio existentiae suae, et erant valde interesting annis. Meum nomen est Kornyakov Dmitry, Linux infrastructuram suppeditans cum prompta promptitudine requisita plus 10 annis. NSPK equos mense Ianuario 2016 coniunxit et, proh dolor, primum initium existentiae societatis non vidit, sed in scaena magnarum mutationum venit.

In genere possumus dicere quod turma nostra 2 producta ministrat pro comitatu. Primum est infrastructurae. Epistulae laborare debent, DNS operari debent, et moderatoris dominii in servientibus te sinere non debent. Comitatu IT landscape ingens est! Hae sunt negotiationes systemata critica & missio, promptitudo requisita aliquot 99,999. Secundum productum est ipsi servientes, corporis et virtualis. Quae exsistentes monitorio sunt necessariae, et novae regulariter clientibus ex multis rebus tradendae sunt. In hoc articulo versari cupimus quomodo infrastructuram enucleavimus quae competit servienti cycli vitae.

initium viarum

Initio itineris nostri, acervus technologicus noster hoc modo respexit:
OS CentOS 7
FreeIPA Domain Controllers
Automation - Ansible (+turris), Sutor

Haec omnia in 3 ditionibus sita sunt, per aliquot centra data divulgata. In una centrum datae sunt systemata et probatio muneris, in reliquis est PROD.

Creando ministris uno in loco hoc simile est;

Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

In the VM template, CentOS minimus est et minimum inquisitum sicut recto /etc/resolv.conf, reliqua per Ansible venit.

CMDB - Excel.

Si minister corporis est, tunc loco apparatus virtualis describendi, OS in ea inauguratus est utens Sutor - MAC inscriptiones scopo servi additae sunt sutoris config, servo accipit locum IP per DHCP, et deinde OS. additur.

Primo etiam conati sumus aliquid facere in Sutoris quadam administratione configurationis. Sed per tempus, hoc problemata portabilitatem configurationum tum ad alia centra data, tum in Ansible codicem ad VMs parandum incepit.

Illo tempore, multi ex nobis Ansible extensionem convenientem Bash perceperunt et non in concha et sed in excogitando skip. Bashsible altiore. Hoc tandem eo perductus est, quod si liber fabularum ob aliquam causam in servo laborabat, facilius erat servo delere, in fabula figere et iterum currere. Per se nulla scriptorum translatio, nulla figurarum portabilitas erat.

Exempli gratia, aliquos config in omnibus servientibus mutare voluimus;

  1. Mutamus configurationem de servientibus existentibus in segmento logico/notitiarum centro. Aliquando non uno die - accessibilitas requisita et lex magnarum numerorum non permittit omnes mutationes simul applicari. Mutationes autem quaedam sunt in potentia destructiva et requirunt aliquid reprimendum - ab officiis ad ipsum OS.
  2. Figens in Ansible
  3. Nos figere in Sutor
  4. Repetere N temporibus pro unaquaque ratione segmenti / Mauris interdum

Ut omnes mutationes aequaliter eant, necesse fuit multas causas considerare, et mutationes constanter occurrere.

  • Refactoring ansible code, configuration files
  • Mutantur internus optimum exercitia
  • Mutationes in eventus analysis incidentium / accidentium
  • Signa securitatis mutantes tam interna quam externa. Exempli gratia, PCI DSS novis requisitis quotannis renovatur

Infrastructura incrementum et initium itineris

Numerus ministrantium / dictionum logicalium / centra datorum crevit, et cum eis numerus errorum in configurationibus. Aliquando ad tres partes devenimus, in quibus figuratio explicanda est:

  1. Automation. Error humanus in operationibus repetitis quam maxime vitandus est.
  2. Repetitio. Facilius est praevidere cum infrastructuram administrare. Servorum et instrumentorum ad earum praeparationem eadem ubique conformatio esse debet. Hoc magni momenti est pro iunctionibus productis - post probationem, praestatio est applicatio ad finem productionis environment conforme conformatus ad testam elit.
  3. Simplicitas et perspicuitas faciendi mutationes in configuratione procurationes.

Reliquum est ut duo instrumenta apponam.

GitLab CE elegimus in nostro codice repositorium, non minimum ad modulorum CI/CD constructum.

Firmamentum secretorum - Hashicorp Vault, incl. magni API.

Testis configurationes et partes ansibilis – Molecule+ Testinfra. Probat multo velocius abire si mitogen ansible coniungis. Eodem tempore incepimus scribere nostrum CMDB et orchestratorem pro automatario instruere (in pictura supra Sutorem), sed haec fabula prorsus alia est, quam collega meus et elit principalis harum systematum in futuro indicabunt.

Nostra optio:

Molecule + Testinfra
Ansible + turrim + AWX
Mundus Servorum + DITNET (propria progressio)
sutor
Gitlab + GitLab cursor
Hashicorp Buy

Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

Viam de muneribus ansilibus. In primis una tantum fuit, sed post aliquot refectionum 17 ex illis facta est, valde suadeo ut monolithum in partes idempotes frangendo, quae tunc separatim emissae esse possunt, praeterea tags addere potes. Munera divisimus per functiones retis, loggings, fasciculos, ferramenta, moleculas etc. In genere consilium infra secuti sumus. Non insisto hanc solam esse veritatem, sed eam nobis fecit.

  • Imitatores "auream imaginem" malum sunt!Praecipuum incommodum est quod prorsus nescis cuius modi imagines nunc sint, et omnes mutationes ad omnes imagines in omnibus praediis virtualisation veniant.
  • Utere lima configuratione default ad minimum, et cum aliis Dicasteriis assentire quae tu responsalis principalis ratio imaginiFor example:
    1. Relinque /etc/sysctl.conf inanes, occasus solum esse debet in /etc/sysctl.d/. Your default in one file, custom for application in another.
    2. Uti primi ante files ad unitates systemd recensere.
  • Omnia configit et includunt omnino, si fieri potest, nulla sed vel eius analoga in libris fabularum
  • Configurationis administratione systematis codice reficiens:
    1. Frange negotium in entia logicalia et rescribe monolith in muneribus
    2. linters utere! Linamentum, yaml-lintectum, etc
    3. Muta accessum tuum! Nullam vel turpis. Status systematis describere necesse est
  • Pro omnibus Ansible muneribus debes scribere probationes in moleculo et relationes generare semel in die.
  • In casu nostro, post probationes praeparandas (quarum plures sunt quam 100), circiter 70000 errorum inventa sunt. Aliquot menses reficere coepit.Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

Nostra implementation

Munera igitur mobilia a linteis parata, consignata et coercita sunt. Etiam gits ubique elevantur. Sed quaestio de certa codicis traditione in diversis segmentis aperta manebat. Scriptis congruere decrevimus. Similis est:

Ab "satu" ad milia ministrantium in centris duodecim data. Quomodo incrementum infrastructurae Linux persecuti sumus?

Postquam mutatio advenit, CI emittitur, server probatio creatur, partes evolvuntur et a moleculo probatae sunt. Si omnia bene est, signum ad prod ramum accedit. Sed novum codicem non apponimus ministrantibus in machina existentibus. Hoc genus spissamentum est quod necessarium est ad magnas facultates systematum nostrorum. Et cum infrastructura ingens fit, magnarum numerorum lex iungitur - etiam si certus sis mutationem esse innoxiam, ad eventus eventus potest ducere.

Multae quoque optiones servientibus creandis sunt. Consuetudo pythonis scriptorum legendi sumus. Et pro ci ansible;

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

Hoc est quod venimus, ut ratio vivat et augeatur.

  • 17 Munera Ansible pro servo erigendi. Singulae functiones destinantur ad munus separatum logicum solvendum (logging, audiendi, usoris auctoritatis, vigilantiae, etc.).
  • Munus probat. Molecule + TestInfra.
  • Propria explicatio: CMDB + Orchestrator.
  • Servo creationis tempus ~30 minuta est, automatum ac propemodum a munere queue separatum.
  • Idem status/nominatio infrastructurae in omnibus segmentis - playbooks, repositoriis, virtualisationi elementis.
  • Cotidie reprehendo status servientis cum generatione relationum in discrepantia cum mensura.

Spero fabulam meam illis qui in principio itineris sunt utilem fore. Quod automation BIBLIOTHECA uteris?

Source: www.habr.com