د تکرار وړ متن ب formatه کې د کوډ په توګه د زیربنا نمایندګي د سیسټمونو لپاره یو ساده غوره تمرین دی چې د موږکانو سره بې ځایه کیدو ته اړتیا نلري. دا عمل یو نوم لري - ، او تر دې دمه د دې پلي کولو لپاره دوه مشهور وسیلې شتون لري ، په ځانګړي توګه په AWS کې: и .
د Terraform او CloudFormation سره تجربه پرتله کول
مخکې له دې چې راشي (هغه ) ما کار وکړ او د دریو کلونو لپاره Terraform کارول. په نوي ځای کې، ما د خپل ټول ځواک سره Terraform هم کارولی، او بیا شرکت د CloudFormation په ګډون د ایمیزون هر څه ته لیږد ته زور ورکړ. ما په ډیر لیوالتیا سره د دواړو لپاره غوره تمرینونه رامینځته کړي ، او دواړه وسیلې یې په خورا پیچلي ، تنظیمي پراخه کاري فلو کې کارولي دي. وروسته، وروسته له هغه چې په فکري توګه د Terraform څخه CloudFormation ته د مهاجرت اغیزې وزن کړو، زه ډاډه شوم چې Terraform شاید د سازمان لپاره غوره انتخاب و.
ترافورم وحشتناک
بیټا سافټویر
Terraform حتی تر اوسه 1.0 نسخه نه ده خپره کړې، کوم چې د دې نه کارولو لپاره ښه دلیل دی. دا ډیر بدل شوی ځکه چې ما لومړی دا پخپله هڅه وکړه، مګر بیا وروسته terraform apply ډیری وختونه د څو تازه معلوماتو وروسته یا په ساده ډول د څو کلونو کارولو وروسته مات شوي. زه به ووایم چې "اوس هر څه توپیر لري،" مګر ... دا هغه څه دي چې هرڅوک یې وايي، نه؟ داسې بدلونونه شتون لري چې د تیرو نسخو سره مطابقت نلري، که څه هم دوی مناسب دي، او حتی داسې احساس کوي چې د منابعو پلورنځیو ترکیب او خلاصون اوس هغه څه دي چې موږ ورته اړتیا لرو. داسې بریښي چې وسیله واقعیا ښه شوې ، مګر ... :-0
له بلې خوا، AWS د شاته مطابقت ساتلو لپاره ښه دنده ترسره کړې. دا شاید د دې لپاره وي چې د دوی خدمات اکثرا په سازمان کې په بشپړه توګه ازمول شوي او یوازې بیا یې نوم بدل شوی، خپور شوی. نو "دوی سخته هڅه وکړه" یو لنډیز دی. د AWS په څیر متنوع او پیچلي سیسټم لپاره د APIs سره شاته مطابقت ساتل خورا خورا ستونزمن کار دی. هر هغه څوک چې باید عامه APIs وساتي چې په پراخه کچه کارول کیږي لکه څنګه چې دوی باید پوه شي چې د څو کلونو لپاره دا کار کول څومره ستونزمن دي. مګر د CloudFormation چلند، زما په حافظه کې، په تیرو کلونو کې هیڅکله بدلون نه دی راغلی.
پښه سره ووینئ ... دا یوه ګولۍ ده
تر هغه ځایه چې زه پوهیږم، سرچینې حذف کړئ بهرنی ستاسو د CF سټیک څخه د کلاوډ فارمیشن سټیک امکان نلري. ورته د Terraform سره ریښتیا ده. دا تاسو ته اجازه درکوي چې موجوده سرچینې ستاسو په سټیک کې وارد کړئ. فعالیت ته حیرانتیا ویل کیدی شي، مګر د لوی ځواک سره لوی مسؤلیت راځي. تاسو یوازې اړتیا لرئ سټیک ته سرچینه اضافه کړئ ، او پداسې حال کې چې تاسو د خپل سټیک سره کار کوئ ، تاسو نشئ کولی دا سرچینه حذف یا بدل کړئ. یوه ورځ یې په شا شو. یوه ورځ په Twitch کې، یو چا په ناڅاپي ډول د بل چا د AWS امنیتي ګروپ په خپل ټیرفارم سټیک کې وارد کړ پداسې حال کې چې هیڅ ډول فساد ته نه و. ما څو کمانډونو ته ننوتل او ... امنیتي ډله (د راتلوونکي ترافیک سره) ورکه شوه.
Terraform عالي
د نامکمل حالتونو څخه بیا رغونه
ځینې وختونه کلاوډ فارمیشن له یو حالت څخه بل ته په بشپړ ډول لیږد کې پاتې راځي. په ورته وخت کې، هغه به هڅه وکړي چې پخواني ته راستون شي. دا د افسوس خبره ده چې دا تل د امکان وړ ندي. دا خورا ډارونکی کیدی شي چې وروسته څه پیښ شوي ډیبګ کړئ - تاسو هیڅکله نه پوهیږئ چې ایا کلاوډ فارمیشن به خوښ وي چې دا هیک کیږي - حتی یوازې د دې حل کولو لپاره. ایا دا به ممکنه وي چې پخوانی حالت ته بیرته راستانه شي، هغه واقعیا نه پوهیږي چې څنګه وټاکي او د ډیفالټ په واسطه، د معجزې په انتظار کې د ساعتونو لپاره ځړول کیږي.
له بلې خوا Terraform د ناکامه لیږدونو څخه په ډیر ښه ډول بیرته راستنیدو ته لیوالتیا لري او د ډیبګ کولو پرمختللي وسیلې وړاندیز کوي.
د سند حالت ته روښانه بدلونونه
"ښه، د بار بیلانسر، تاسو بدل یاست. خو څنګه؟"
- اندیښمن انجنیر، د "منلو" تڼۍ فشارولو ته چمتو دی.
ځینې وختونه زه اړتیا لرم چې د CloudFormation سټیک کې د بار بیلنسر سره ځینې لاسوهنې ترسره کړم، لکه د پورټ شمیره اضافه کول یا د امنیت ګروپ بدلول. clouFormation په کمزوري ډول بدلونونه ښیې. زه ، په پنونو او ستنو کې ، د یامل فایل لس ځله چیک کړم ترڅو ډاډ ترلاسه کړم چې ما هیڅ اړین شیان نه دي حذف کړي او هیڅ غیر ضروري ندي اضافه کړي.
Terraform پدې برخه کې ډیر شفاف دی. ځینې وختونه هغه حتی خورا شفاف وي (لوستل: ستړي کوونکی). خوشبختانه، په وروستي نسخه کې د بدلونونو ښه ښودل شامل دي نو تاسو اوس کولی شئ په سمه توګه وګورئ چې څه بدلیږي.
انعطاف
سافټویر شاته ولیکئ.
د دې لپاره چې په واضح ډول ووایم، د اوږدمهاله سافټویر ترټولو مهم ځانګړتیا د بدلون سره د تطبیق وړتیا ده. کوم سافټویر شاته ولیکئ. ډیری وختونه ما د "ساده" خدمت په اخیستو سره خطاګانې کړې ، او بیا په یو واحد کلاوډ فارمیشن یا ټیرفارم سټیک کې د هرڅه کرم کول پیل کوم. او البته، میاشتې وروسته څرګنده شوه چې ما په هرڅه غلط پوهیدلی و، او خدمت واقعیا ساده نه و! او اوس زه اړتیا لرم چې په یو ډول لوی سټیک په کوچنیو برخو مات کړم. کله چې تاسو د CloudFormation سره کار کوئ، دا یوازې د لومړي ځل لپاره د موجوده سټیک په جوړولو سره ترسره کیدی شي، او زه دا زما د ډیټابیسونو سره نه کوم. له بلې خوا Terraform دا ممکنه کړه چې سټیک تحلیل کړي او په ډیرو پوهیدو وړ کوچنیو برخو کې یې مات کړي.
په git کې ماډلونه
د ډیری سټیکسونو په اوږدو کې د Terraform کوډ شریکول د CloudFormation کوډ شریکولو په پرتله خورا اسانه دي. د Terraform سره ، تاسو کولی شئ خپل کوډ د git ذخیره کې وساتئ او د سیمانټیک نسخه کنټرول په کارولو سره ورته لاسرسی ومومئ. هرڅوک چې دې ذخیره ته لاسرسی ولري کولی شي شریک شوی کوډ بیا وکاروي. د کلاوډ فارمیشن مساوي S3 دی ، مګر دا ورته ګټې نلري ، او هیڅ دلیل شتون نلري چې ولې موږ باید د S3 په ګټه git پریږدو.
سازمان وده وکړه او د ګډ سټیکونو شریکولو وړتیا خورا مهمې کچې ته ورسیده. Terraform دا ټول اسانه او طبیعي کوي ، پداسې حال کې چې CloudFormation به تاسو ته د هوپس له لارې کود وکړي مخکې لدې چې تاسو د دې کار په څیر یو څه ترلاسه کړئ.
د کوډ په توګه عملیات
"راځئ چې دا سکریپټ کړو او سمه ده."
- یو انجینر 3 کاله مخکې د Terraform بایسکل اختراع.
کله چې دا د سافټویر پراختیا ته راځي، Go یا د جاوا پروګرام یوازې کوډ نه دی.
د کوډ په توګه کوډ
دلته زیربنا هم شتون لري چې دا کار کوي.
د کوډ په توګه زیربنا
خو هغه د کوم ځای دی؟ څنګه یې څارنه وکړو؟ ستاسو کوډ چیرته ژوند کوي؟ ایا پراختیا کونکي د لاسرسي اجازې ته اړتیا لري؟
د کوډ په توګه عملیات
د سافټویر جوړونکي کیدل یوازې د کوډ لیکلو معنی نلري.
AWS یوازینی نه دی: تاسو شاید نور چمتو کونکي کاروئ. SignalFx، PagerDuty یا Github. شاید تاسو د CI/CD لپاره داخلي جینکنز سرور یا د څارنې لپاره داخلي ګرافانا ډشبورډ ولرئ. د کوډ په توګه انفراسیون د مختلف دلیلونو لپاره غوره شوی، او هر یو د سافټویر پورې اړوند هر څه لپاره مساوي مهم دی.
کله چې ما په Twitch کې کار کاوه، موږ د ایمیزون مخلوط ایمبیډ شوي او AWS سیسټمونو کې خدمتونه ګړندي کړل. موږ د ډیری مایکرو خدماتو ملاتړ وکړ او عملیاتي لګښتونه مو زیات کړل. بحثونه په دې ډول روان وو:
- Я: لعنت، دا د یو مایکرو سرویس د زیاتولو لپاره ډیری اشارې دي. زه باید دا کثافات د AWS حساب جوړولو لپاره وکاروم (موږ 2 حسابونو ته لاړو کوچني خدمتونه)، بیا دا د خبرتیاو ترتیب کولو لپاره، دا د کوډ ذخیره کولو لپاره، او دا د بریښنالیک لیست لپاره، او بیا دا ...
- لیډ: راځئ چې دا سکریپټ وکړو او سمه ده.
- Я: سمه ده، خو رسم الخط به پخپله بدل شي. موږ به یوې لارې ته اړتیا ولرو چې وګورو چې دا ټول جوړ شوي ایمیزون ګیزموس تازه دي.
- لیډ: ډیر ښه. او موږ به د دې لپاره سکریپټ ولیکو.
- Я: غوره! او سکریپټ به شاید لاهم د پیرامیټونو تنظیم کولو ته اړتیا ولري. ایا هغه به یې ومني؟
- لیډ: اجازه راکړئ چې هغه چیرته ځي!
- Я: پروسه ممکن بدله شي او شاته مطابقت به له لاسه ورکړي. یو ډول سیمانټیک نسخه کنټرول به اړین وي.
- لیډ: ډیر ښه نظر!
- Я: وسیلې په لاسي ډول بدل کیدی شي ، د کارن انٹرفیس دننه. موږ به د دې چک کولو او حل کولو لپاره یوې لارې ته اړتیا ولرو.
۳ کاله وروسته:
- لیډ: او موږ ټرافارم ترلاسه کړ.
د کیسې اخلاق دا دي: حتی که تاسو په ایمیزون کې په هر څه کې د پښو پر سر سر، تاسو لاهم یو څه کاروئ چې د AWS څخه نه وي، او دا خدمتونه یو حالت لري چې د ترتیب کولو ژبه کاروي ترڅو دا حالت په همغږي کې وساتي.
د کلاوډ فارمیشن لامبډا بمقابله د ګیټ ماډلونه ټرافارم
لامبډا د دودیز منطق مسلې لپاره د کلاوډ فارمیشن حل دی. د لامبډا سره تاسو کولی شئ او یا . دا طریقه اضافي پیچلتیاوې معرفي کوي چې د ګیټ ماډلونو د Terraform په سیمانټیک نسخه کې شتون نلري. زما لپاره، ترټولو مهمه ستونزه د دې ټولو کاروونکو لیمبډا لپاره د اجازې اداره کول وه (او دا لسګونه AWS حسابونه دي). بله مهمه ستونزه دا وه چې "لومړی څه راغلل، چرګ یا هګۍ؟" ستونزه: دا د لامبډا کوډ پورې اړه درلوده. دا فنکشن پخپله زیربنا او کوډ دی، او دا پخپله څارنې او تازه معلوماتو ته اړتیا لري. په تابوت کې وروستی کیل د لامبډا کوډ بدلونونو په سمینټیک ډول تازه کولو کې ستونزه وه؛ موږ باید ډاډ ترلاسه کړو چې د سټیک کړنې پرته له مستقیم قوماندې څخه د منډو تر مینځ بدلون نه کوي.
زما په یاد دي یوځل چې ما غوښتل د کلاسیک بار بیلنسر سره د لچک لرونکي بینسټالک چاپیریال لپاره کانري ګمارنه رامینځته کړم. د ترسره کولو لپاره ترټولو اسانه کار به دا وي چې د تولید چاپیریال ته نږدې د EB لپاره دوهم ګمارنه ترسره کړئ، دا یو ګام نور هم پورته کړئ: د تولید چاپیریال کې د ځای پرځای کولو LB سره د اتوماتیک پیمانه کانري ګمارلو ګروپ ترکیب. او له هغه وخته چې Terraform کاروي ، دا به په Terraform کې د کوډ 4 اضافي لینونو ته اړتیا ولري. کله چې ما وپوښتل چې ایا په CloudFormation کې د پرتلې وړ حل شتون لري ، دوی ما ته د ګیټ بشپړ ذخیره ته اشاره وکړه چې د پلي کولو پایپ لاین او هرڅه سره ، ټول د یو څه لپاره چې د Terraform کوډ ضعیف 4 لینونه کولی شي ترسره کړي.
دا په ښه توګه تودوخه کشف کوي
ډاډ ترلاسه کړئ چې واقعیت د توقعاتو سره سمون لري.
د کوډ ځانګړتیا په توګه خورا پیاوړي عملیات دي ځکه چې دا د دې ډاډ ترلاسه کولو کې مرسته کوي چې واقعیت د تمې سره سمون لري. دا د CloudFormation او Terraform دواړو سره شتون لري. مګر لکه څنګه چې د تولید سټیک وده وکړه ، په کلاوډ فارمیشن کې د ډریف لټون ډیر او ډیر غلط کشفونه تولید کړل.
د Terraform سره تاسو د ډریف کشف لپاره خورا پرمختللي ژوند سایکل هکونه لرئ. د مثال په توګه، تاسو کمانډ داخل کړئ په مستقیم ډول د ECS کاري تعریف کې که تاسو غواړئ په ځانګړي کاري تعریف کې بدلونونه له پامه غورځوئ پرته لدې چې ستاسو د ECS ټول ګمارنې کې بدلونونه له پامه غورځول شي.
CDK او د کلاوډ فارمیشن راتلونکی
کلاوډ فارمیشن په لوی ، کراس - زیربنا پیمانه اداره کول ګران دي. ډیری دا مشکلات پیژندل شوي او وسیله ورته شیانو ته اړتیا لري ، په کوډ کې د کلاوډ زیربنا تعریف کولو او د AWS CloudFormation له لارې د چلولو لپاره چوکاټ. دا به په زړه پورې وي چې وګورو چې راتلونکی د aws-cdk لپاره څه لري، مګر دا به د Terraform د نورو پیاوړتیاوو سره سیالي سخت وخت ولري؛ د CloudFormation تازه کولو لپاره، نړیوال بدلونونه به اړین وي.
تر څو ټرفارم مایوسه نه کړي
دا "د کوډ په توګه زیربنا" ده، او نه "د متن په توګه".
د Terraform په اړه زما لومړی تاثر خورا خراب و. زه فکر کوم چې زه یوازې په طریقه نه پوهیږم. نږدې ټول انجنیران په غیر ارادي ډول دا د متن ب formatه پیژني چې اړتیا لري په مطلوب زیربنا بدل شي. دا په دې طریقه مه کوئ.
د ښه سافټویر پراختیا حقیقتونه په Terraform کې هم پلي کیږي.
ما د ښه کوډ رامینځته کولو لپاره ډیری تمرینونه لیدلي چې په Terraform کې له پامه غورځول شوي. تاسو د کلونو لپاره زده کړه کړې ترڅو یو ښه پروګرامر شئ. دا تجربه مه پریږدئ ځکه چې تاسو د Terraform سره کار کوئ. د ښه سافټویر پراختیا حقیقتونه په Terraform کې پلي کیږي.
کوډ څنګه مستند نشي؟
ما د هیڅ اسنادو پرته لوی ټیرفارم سټیکونه لیدلي دي. تاسو څنګه کولی شئ په پاڼو کې کوډ ولیکئ - پرته له کوم اسنادو سره؟ هغه اسناد اضافه کړئ چې ستاسو تشریح کوي کوډ Terraform (د "کوډ" کلمه باندې ټینګار)، ولې دا برخه خورا مهمه ده، او تاسو څه کوئ.
موږ څنګه کولی شو هغه خدمات ځای په ځای کړو چې یو وخت یو لوی اصلي () فعالیت و؟
ما د یو واحد ماډل په توګه وړاندې شوي خورا پیچلي Terraform سټیکونه لیدلي دي. ولې موږ دا ډول سافټویر نه پلي کوو؟ ولې موږ لوی فعالیتونه په کوچنیو ویشو؟ ورته ځوابونه په Terraform کې پلي کیږي. که ستاسو ماډل خورا لوی وي، تاسو اړتیا لرئ چې دا په کوچنیو ماډلونو کې مات کړئ.
ایا ستاسو شرکت کتابتونونه نه کاروي؟
ما ولیدل چې څنګه انجینرانو د Terraform په کارولو سره یوه نوې پروژه رامینځته کړه ، په احمقانه ډول د نورو پروژو څخه لوی ټوټې په خپلو کې کاپي کړې ، او بیا یې له دوی سره د کار پیل کولو پورې ټینکر کاوه. ایا تاسو به په خپل شرکت کې د "جنګ" کوډ سره دا ډول کار وکړئ؟ موږ یوازې کتابتونونه نه کاروو. هو، مګر موږ په اصولو کې د ګډ کتابتونونو پرته چیرته یو؟!
ایا تاسو PEP8 یا gofmt نه کاروئ؟
ډیری ژبې یو معیاري، منل شوي فارمیټینګ سکیم لري. په Python کې دا PEP8 دی. په Go کې - gofmt. Terraform خپل لري: terraform fmt. د خپل روغتیا لپاره یې خوند واخلئ!
ایا تاسو به د جاواسکریپټ پوهیدو پرته عکس العمل وکاروئ؟
د Terraform ماډلونه کولی شي د پیچلي زیربنا ځینې برخې ساده کړي چې تاسو یې رامینځته کوئ ، مګر دا پدې معنی ندي چې تاسو نشئ کولی له هغې سره ټکر وکړئ. غواړئ د سرچینو د پوهیدو پرته Terraform په سمه توګه وکاروئ؟ تاسو برباد یاست: وخت به تیر شي، او تاسو به هیڅکله د ټرافورم ماسټر نشئ.
ایا تاسو د واحدونو یا انحصار انجیکشن سره کوډ کوئ؟
د انحصار انجیکشن د سافټویر پراختیا لپاره یو پیژندل شوی غوره عمل دی او د واحدونو په پرتله غوره کیږي. دا څنګه په Terraform کې ګټور دی؟ ما د Terraform ماډلونه لیدلي چې په لرې پرتو حالت پورې اړه لري. د هغه ماډلونو لیکلو پرځای چې لیرې حالت بیرته ترلاسه کوي، یو ماډل ولیکئ چې پیرامیټونه اخلي. او بیا دا پیرامیټونه ماډل ته انتقال کړئ.
ایا ستاسو کتابتونونه لس شیان ښه کوي یا یو ښه شی؟
هغه کتابتونونه چې غوره کار کوي هغه دي چې په یو کار تمرکز کوي چې دوی خورا ښه ترسره کوي. د لوی Terraform ماډلونو لیکلو پرځای چې هڅه کوي هرڅه په یوځل ترسره کړي ، د دوی برخې رامینځته کړئ چې یو کار ښه ترسره کوي. او بیا یې د اړتیا سره سم یوځای کړئ.
تاسو څنګه د شاته مطابقت پرته په کتابتونونو کې بدلون راوړئ؟
یو عام Terraform ماډل، د منظم کتابتون په څیر، اړتیا لري چې په یو ډول سره کاروونکو ته بدلونونه خبر کړي پرته له دې چې شاته مطابقت ولري. دا د خندا وړ دی کله چې دا بدلونونه په کتابتونونو کې پیښیږي، او دا هماغسې ځورونکی دی کله چې غیر شاته - مطابقت لرونکي بدلونونه د Terraform ماډلونو کې رامینځته کیږي. دا سپارښتنه کیږي چې د ګیټ ټګز او سیمر وکاروئ کله چې د Terraform ماډلونو کاروئ.
ایا ستاسو د تولید خدمت ستاسو په لپ ټاپ یا د معلوماتو مرکز کې روان دی؟
Hashicorp په څیر وسایل لري ستاسو د ټراففارم چلولو لپاره. دا مرکزي شوي خدمتونه د ټرافورم بدلونونو اداره کول، پلټنه او تصویب کول اسانه کوي.
ایا تاسو ازموینې نه لیکئ؟
انجنیران پیژني چې کوډ باید ازموینې ته اړتیا ولري، مګر دوی پخپله د ټیرفارم سره کار کولو پر مهال د ازموینې په اړه هیر کړي. د زیربنا لپاره، دا د غدارو شیبو څخه ډک دی. زما مشوره دا ده چې د ماډلونو په کارولو سره "ازموینه" یا "مثال رامینځته کړئ" سټیکونه چې د CI/CD په جریان کې د ازموینې لپاره په سمه توګه ګمارل کیدی شي.
Terraform او microservices
د مایکرو خدماتو شرکتونو ژوند او مرګ د نوي مایکرو سرویس ورک سټیکونو سرعت ، نوښت او ګډوډي پورې اړه لري.
ترټولو عام منفي اړخ چې د مایکرو سرویس معمارۍ سره تړاو لري، او کوم چې له مینځه وړل کیدی نشي، د کار سره تړاو لري، نه کوډ. که تاسو د ټیرفارم په اړه فکر کوئ چې یوازې د مایکرو سرویسس معمارۍ یوازې زیربنا اړخ اتومات کولو لپاره لاره ده ، نو تاسو د سیسټم ریښتیني ګټې له لاسه ورکوئ. اوس دا لا دمخه ده .
سرچینه: www.habr.com