Incipiemus nostrum blog cum publicationibus innixum in orationibus proximis directoris nostri technici (Dmitry Stolyarov). Omnes hi anno 2016 variis eventibus professionalibus factae sunt et dedicatae sunt argumento DevOps et Docker. Unum video e Docker Moscuae conventu in officio Badoo, iam habemus Online. Novae comitantur articuli qui essentiam relationum deferunt. Itaβ¦
May XXXI ad colloquium Pars festivitatis "Russian Internet Technologies" (RIT++ 2016) habetur, sectio "continua instruere et instruere" aperitur cum relatione "Optimus Exercitia continuae traditionis cum Docker". Optima exercitia compenditavit et ordinavit ad faciendam continuam traditionem (CD) processum utendi Docker et aliis effectibus Open Source. Hisce solutionibus in productione laboramus, quod nos experientia practica niti sinit.
Si tempus terere horae vigilantibus in plena commendamus. Alioquin infra summa summarium in textu forma est.
Continua Delivery cum Docker
sub continua Delivery rerum seriem intellegimus consequenter, quarum applicatio codicis a Git repositorio primum ad producendum venit, deinde in archivo desinit. Hoc sic videtur: Git β Expertus β aedificate β Expertus β Operate.
Pleraque fama vacat scaenam aedificare (applicationes conventus), et argumenta emissionis et operandi breviter attinguntur. Loquemur de quaestionibus et de exemplaribus, quae eas solvere sinunt, et exsecutiones specificae harum exemplarium differre possunt.
Quorsum hic Docker opus est? Nihil non est quod de consuetudinibus continuis traditionis loqui decrevimus in contextu huius Instrumenti aperti Source. Etsi tota relatio in usum eius versatur, multae rationes aperiuntur cum considerando principale exemplar applicationis codice rollout.
Pelagus rollout exemplaris
Cum igitur novas applicationis versiones evolvimus, certe adversae sunt downtime quaestiogeneratae in commutatione servo productionis. Negotiatio ex veteri versione applicationis ad novam statim flectere non potest: primum pro certo habendum est novam versionem non solum feliciter receptam esse, sed etiam "calefactum" (i.e., ad petitiones serviendas omnino paratas).
Ita per aliquod tempus utraque versiones applicationis (veteris et novae) simul operabuntur. Quod sponte ducit ad participatur resource conflictus: retis, ratio fasciculi, IPC, etc. Cum Docker, hoc problema facile solvitur per currendo varias versiones applicationis in vasis separatis, pro quo auxilium solitudo intra eundem exercitum (servi/machinae virtualis) praestatur. Utique sine velit sine aliqua dolis, si promptum est et opportunum instrumentum, contraria ratio est, non praetermittendum.
Continentiaeizatio multa alia beneficia instruxit. Omni applicatione pendent specifica versionem (Vel versio range) interpres, dispositio modulorum / extensionum, etc., necnon versiones eorum. Idque non solum in ambitu exsecutabili, sed etiam in universo ambitu, etiam systema software " eiusque versio (usque ad Linux distributionem adhibita). Ex eo quod continentia non solum codicem applicationis continent, sed etiam systema praeordinatum et programmatum programmatis inquisitorum versionum, oblivisci potes circa problemata cum dependentiis.
Summatim fiat scriptor principalis rollout exemplaris novis versionibus attentis sequentium factorum:
- Primo, vetus litera applicatio in primo vase decurrit.
- Nova versio deinde in vase secundo evolvit et "calefactum" est. Notabile est quod haec nova versio ipsa non solum codicem applicationem renovatum, sed etiam quamlibet eius clientelas, ac systematicam (exempli gratia, novam versionem OpenSSL vel totam distributionem portare potest) notabile est.
- Cum nova versio plene petitionibus inservire parata est, negotiatio permutat a primo vase ad secundum.
- Vetus versio nunc omissus est.
Hic accessus explicandi varias versiones applicationis in vasis separatis aliud commodum praebet - velox reverti ad versionem veterem (post omnia satis est negotiationem ad vas desideratum commutandum).
Ultima prima commendatio aliquid sonat quod etiam capitaneus reprehendere non potuit: "[In organising continuum Delivery cum Docker] Usus Docker [et intellige quid dat]" Memento, hoc non est glans argentea quae omnem quaestionem solvet, sed instrumentum, quod mirabile fundamentum praebet.
Reproducibility
Per "reproducibilitatem" intelligimus problematum copiam generatim occurrere cum applicationibus operandi. De talibus loquimur:
- Scripta a qualitate departmentis choragi coercita accurate in productione exprimi debet.
- Applicationes publicantur in servientibus qui sarcinas recipere possunt ex speculis repositoriis diversis (supra tempus renovantur, et cum eis versiones applicationum inaugurariarum).
- "Omnia operatur in me localiter!" [...]
- Opus est ut in versione veteri aliquid inspicias.
- ...
Eorum essentia generalis eo usque ulcera est, ut plena obsequio ambitus adhibeatur (velut absentia factoris humani) necessaria est. Quomodo reproducibilitatem spondemus? Fac imagines Docker in codice ex Git fundata, ac deinde iis utere ad aliquod opus: in sitibus testium, in productione, in machinis programmatum localium... Simul, interest ut actiones quae peraguntur obscuratis. ΠΏΠΎΡΠ»Π΅ convenientem imaginem: quo simplicius, eo minus probabiles errores sunt.
Infrastructure est codice
Si requisita infrastructura (disponibilitatis programmatis servientis, eius versionis, etc.) non formalizatae sunt et "programmata", tunc volvens cuiuslibet renovationis applicationis in prosperis consectationibus provenire potest. Exempli gratia, in choragiis iam ad PHP 7.0 transivisti et codicem ita rescripsisti - deinde eius species in productione cum aliquo vetere PHP (5.5) aliquem certe mirabitur. Maioris mutationis in versione interpretis non licet oblivisci, sed "diabolus in singulis": mirum fortasse in minore renovatione cuiuslibet dependentiae.
Accessus ad solvendam hanc quaestionem notum est IaC (Infrastructure as Code, "infrastructure as code") et involvit accommodandi necessitates infrastructuram cum schedula codice. Utens ea, tincidunt et DevOps periti operari possunt cum eadem applicatione Git repositorium, sed in diversis partibus eius. Ex hoc codice imago Docker in Git creatum est, in quo applicatio explicatur ratione omnium propriae infrastructure. Simpliciter positum, scripta (praecepta) ad imagines congregandas in eodem promptuario cum fonte codice coalescere debent et coalescere.
In applicatione multi-strati architecturae - exempli gratia nginx est, quae ante applicationem iam in medio vase Docker currentis stat - imagines Docker ex codice in Git pro singulis iacuis creari debent. Tunc prima imago applicationem cum interprete et aliis "clausis" clientibus continebit, et altera imago nginx fluminis continebit.
Docker imagines, communicatio cum Git
Omnes imagines Docker ex Git in duo genera collecta dividimus: tempus et emissio. Temporaria imagines tagged nomine rami in Git, proxime adul- tari potest et evolvit tantum ad praevisum (non ad productionem). Haec est differentia eorum emissiones: numquam scis, quae in eis sint.
Sensum facit colligere in imagines temporarias: ramus domini (potest sponte evolvi ad locum separatum ut assidue videatur hodiernam versionem domini), ramos cum emissione, ramos innovationum specificarum.
Post praevisionem imaginum temporalium opus translationis in productionem venit, tincidunt quendam tag pone. Automatice collecta tag dimittis imaginem (the tag correspondet tag a Git) et evolvitur ad choragium. Si bene verificatur per qualitatem department, ad productionem accedit.
Dapp
Omnia quae descripti sunt (rollout, conventus imaginis, conservationem sequentem) perfici possunt independenter a scriptis Bash et aliis instrumentis "improvis". Sed si hoc feceris, quandoque exsecutionem deducet ad magnam multiplicitatem et ad pauperum moderabilitatem. Hoc intelligentes, venimus creare propriam propriam Workflow utilitatem ad CI/CD - aedificandi. Dapp.
Fons eius codicis in Ruby, fonte aperto et edito scriptus est . Infeliciter, documenta punctum instrumenti infirmissimum est, sed in eo laboramus. Et scribemus ad te plus quam semel de dapp, quia... Exspectare non possumus sincere communicare facultates suas cum tota communitate quorum interest, sed interim mitte quaestiones tuas et petitiones collige et/vel progressionem propositi in GitHub sequere.
Renovata August XIII, MMXIX: currently in project Dapp renamed to Codex eius in Go omnino rescriptus est, eiusque documentum insigniter emendatum est.
Kubernetes
Aliud paratum apertum Source instrumentum, quod iam significant recognitionem in ambitu professionali factum est Kubernetes, Docker botrus procuratio. Thema eius usus in operando consiliorum in Docker aedificatorum extra ambitum relationis est, ideo propositio limitatur ad contemplationem aliquarum notarum interesting.
pro rollout, Kubernetes offert;
- promptitudo probe - inhibenda promptitudo novae versionis applicationis (ad commutandum commercium ad eam);
- volvens renovatio - sequentialis imago renovatio in botro vasorum (sutdown, renovatio, praeparatio ad launch, commercium commutatione);
- synchrona renovatio - adaequationis imaginis in botro cum accessu diverso: primum in dimidia parte continentis, dein in reliquis;
- canaria emissiones - novam imaginem in stricto (minivo) numero vasorum ad anomalias monitoris deducendo.
Cum Continua pronuntiatio non solum emissio novae versionis, Kubernetes plures facultates habet ad sustentationem infrastructuram subsequentem: constructum in vigilantia et colligatione pro omnibus vasis, scalis automaticis, etc. Haec omnia iam operatur et iustum exspectat exsecutionem in processibus tuis.
Suasiones finales
- Utere Docker.
- Crea Docker imagines applicationum pro omnibus necessitatibus tuis.
- Principium sequere "Infrastructura est signum."
- Link Git to Docker.
- Ordinare ordinem rollout.
- Parato facto tribunali utere (Kubernetes or another).
Videos et labitur
Video a perficiendi (circa horam) (renuntiatio ipsa incipit a momento 5 - nexum sequi ex hoc momento ludere).
Exhibitio relationis;
PS
Aliae relationes de argumento nostro diarii:
- «» (Dmitry Stolyarov; 27 Maii 2019 apud DevOpsConf);
- «» (Dmitry Stolyarov; November VII, MMXVII in HighLoad ++);
- «» (Dmitry Stolyarov; November VII, MMXVII in HighLoad ++);
- «» (Dmitry Stolyarov; VI Iunii, MMXVII apud RootConf).
Source: www.habr.com