به نظر می رسد که توسعه دهندگان Terraform بهترین شیوه های بسیار راحت را برای کار با زیرساخت AWS ارائه می دهند. فقط یک تفاوت ظریف وجود دارد. با گذشت زمان، تعداد محیط ها افزایش می یابد، ویژگی هایی در هر یک ظاهر می شود. تقریباً یک کپی از پشته برنامه در منطقه همسایه ظاهر می شود. و کد Terraform باید با دقت کپی و مطابق با نیازهای جدید یا برای ایجاد یک دانه برف کپی و ویرایش شود.
گزارش من در مورد الگوهای Terraform برای مبارزه با هرج و مرج و روال دستی در پروژه های بزرگ و طولانی است.
ویدئو:
من 40 سال دارم، 20 سال است که در زمینه فناوری اطلاعات هستم. من 12 سال است که در Ixtens کار می کنم. ما درگیر توسعه مبتنی بر تجارت الکترونیک هستیم. و من 5 سال است که تمرینات DevOps را تمرین می کنم.
داستان من در مورد تجربه یک پروژه در شرکتی است که نامش را نمی گویم و پشت یک قرارداد عدم افشا پنهان شده است.
اعداد روی اسلاید به منظور درک محدوده پروژه آورده شده است. و هر چیزی که در ادامه خواهم گفت به آمازون مربوط می شود.
من 4 سال پیش به این پروژه پیوستم. و بازسازی زیرساخت در نوسان کامل بود، زیرا پروژه رشد کرده بود. و آن الگوهایی که استفاده شد، دیگر مناسب نیستند. و با توجه به رشد برنامه ریزی شده پروژه، لازم بود چیز جدیدی ارائه شود.
با تشکر از Matvey، که دیروز به ما گفت که در پیتزا دودو چه اتفاقی افتاده است. این چیزی است که 4 سال پیش برای ما اتفاق افتاد.
توسعه دهندگان آمدند و شروع به ساخت کد زیرساخت کردند.
واضح ترین دلایلی که چرا این مورد نیاز بود زمان برای بازاریابی بود. لازم بود اطمینان حاصل شود که تیم DevOps در هنگام عرضه یک گلوگاه نیست. و از جمله Terraform و Puppet در همان سطح اول استفاده شد.
Terraform یک پروژه منبع باز از HashiCorp است. و برای کسانی که اصلاً نمی دانند چیست، چند اسلاید بعدی.
زیرساخت به عنوان کد به این معنی است که ما می توانیم زیرساخت خود را توصیف کنیم و از برخی ربات ها بخواهیم که مطمئن شوند منابعی را که توضیح دادیم دریافت می کنیم.
به عنوان مثال، ما به یک ماشین مجازی نیاز داریم. ما توضیح خواهیم داد، چند پارامتر مورد نیاز را اضافه می کنیم.
پس از آن، دسترسی به آمازون را در کنسول پیکربندی می کنیم. و طرح Terraform را بخواهید. طرح Terraform خواهد گفت: "خوب، برای منبع شما، ما می توانیم این کارها را انجام دهیم." و حداقل یک منبع اضافه خواهد شد. و هیچ تغییری انتظار نمی رود.
بعد از اینکه همه چیز برای شما مناسب بود، می‌توانید از Terraform درخواست کنید و Terraform یک نمونه برای شما ایجاد کند و یک ماشین مجازی در فضای ابری خود دریافت کنید.
علاوه بر این، پروژه ما توسعه می یابد. ما در حال اضافه کردن برخی تغییرات در آنجا هستیم. ما برای نمونه های بیشتر درخواست می کنیم، ما 53 ورودی اضافه می کنیم.
و ما تکرار می کنیم. لطفا برنامه ریزی کنید می بینیم که چه تغییراتی برنامه ریزی شده است. درخواست دادن. و بنابراین زیرساخت های ما رشد می کند.
Terraform از چیزی به عنوان فایل های حالت استفاده می کند. یعنی تمام تغییراتی که به آمازون می رود را در یک فایل ذخیره می کند، جایی که برای هر منبعی که توضیح دادید، منابع مربوطه وجود دارد که در آمازون ایجاد شده است. بنابراین، هنگام تغییر شرح یک منبع، Terraform دقیقا می داند که چه چیزی باید در آمازون تغییر کند.
این فایل های حالت در اصل فقط فایل بودند. و ما آنها را در Git ذخیره کردیم که بسیار ناخوشایند بود. دائماً شخصی فراموش می کرد که تغییراتی را انجام دهد و درگیری های زیادی وجود داشت.
اکنون می توان از backend استفاده کرد، یعنی Terraform نشان داده شده است که در کدام سطل، با کدام کلید فایل حالت باید ذخیره شود. و Terraform خود مراقبت از دریافت این فایل حالت، انجام تمام جادو و برگرداندن نتیجه نهایی خواهد بود.
زیرساخت های ما در حال رشد است. کد ما اینجاست. و اکنون ما نمی خواهیم فقط یک ماشین مجازی ایجاد کنیم، بلکه می خواهیم یک محیط آزمایشی داشته باشیم.
Terraform به شما امکان می دهد چیزی را به عنوان یک ماژول بسازید، یعنی همان چیزی را در یک پوشه توصیف کنید.
و مثلاً در تست، این ماژول را صدا بزنید و همان چیزی را بگیرید که انگار Terraform application را در خود ماژول انجام می دهیم. این کد برای تست است.
برای تولید، می‌توانیم تغییراتی را به آنجا بفرستیم، زیرا در آزمایش نیازی به نمونه‌های بزرگ نداریم، در تولید نمونه‌های بزرگ مفید خواهند بود.
و سپس به پروژه برمی گردم. کار دشواری بود، زیرساخت ها بسیار بزرگ برنامه ریزی شده بود. و لازم بود به نحوی همه کدها قرار داده شود تا برای همه راحت باشد: برای کسانی که این کد را تعمیر می کنند و برای کسانی که تغییراتی ایجاد می کنند. و برنامه‌ریزی شده بود که هر توسعه‌دهنده‌ای بتواند برود و زیرساخت لازم را برای قسمت خود از پلتفرم تعمیر کند.
این یک درخت دایرکتوری است که توسط HashiCorp توصیه می شود اگر پروژه بزرگی دارید و منطقی است که کل زیرساخت را به چند قطعه کوچک تقسیم کنید و هر قطعه را در یک پوشه جداگانه توصیف کنید.
با داشتن یک کتابخانه منابع گسترده، می توانید در مورد همان موضوع در آزمایش و تولید تماس بگیرید.
در مورد ما، این کاملاً مناسب نبود، زیرا پشته آزمایشی برای توسعه دهندگان یا برای آزمایش باید به نحوی ساده تر به دست می آمد. و من نمی‌خواستم پوشه‌ها را مرور کنم و به ترتیب درست اعمال کنم و نگران باشم که پایه بالا بیاید و سپس نمونه‌ای که از این پایه استفاده می‌کند بالا بیاید. بنابراین، تمام تست ها از یک پوشه راه اندازی شد. همان ماژول ها در آنجا فراخوانی شدند، اما همه چیز در یک اجرا انجام شد.
Terraform از تمام وابستگی ها مراقبت می کند. و همیشه منابعی را در آن دنباله ایجاد می کند تا بتوانید یک آدرس IP مثلاً از یک نمونه تازه ایجاد شده دریافت کنید و این آدرس IP را در ورودی route53 دریافت کنید.
علاوه بر این، پلت فرم بسیار بزرگ است. و اجرای یک پشته آزمایشی، حتی اگر برای یک ساعت، حتی برای 8 ساعت، یک تجارت بسیار گران است.
و ما این تجارت را خودکار کرده ایم. و کار جنکینز به پشته اجازه اجرا داد. لازم بود یک درخواست کشش در آن با تغییراتی که توسعه دهنده می خواهد آزمایش کند، تمام گزینه ها، اجزا و اندازه های لازم را مشخص کند. اگر او خواهان تست عملکرد است، می تواند نمونه های بیشتری را انجام دهد. اگر او فقط باید بررسی کند که برخی از فرم ها باز می شود، می تواند از حداقل دستمزد شروع کند. و همچنین مشخص کنید که آیا به خوشه نیاز است یا خیر و غیره.
و سپس جنکینز یک اسکریپت پوسته را فشار داد که کمی کد موجود در پوشه Terraform را تغییر داد. حذف فایل های غیر ضروری، اضافه کردن فایل های لازم. و سپس، با یک بار اجرای Terraform، پشته افزایش یافت.
و سپس مراحل دیگری وجود داشت که من نمی خواهم وارد آنها شوم.
با توجه به اینکه برای تست به گزینه های کمی بیشتر از زمان تولید نیاز داشتیم، مجبور شدیم از ماژول ها کپی کنیم تا بتوانیم در این نسخه ها آن ویژگی هایی را که فقط در تست مورد نیاز است اضافه کنیم.
و این طور شد که در تست، به نظر می رسد که می خواهید آن تغییراتی را آزمایش کنید که در نهایت به تولید می رسند. اما در واقع یک چیز مورد آزمایش قرار گرفت و کمی متفاوت در تولید استفاده شد. و یک شکست کوچک در الگو ایجاد شد که در تولید تمام تغییرات توسط تیم عملیات اعمال شد. و گاهی معلوم می شد که آن تغییراتی که قرار بود از تست به تولید برود، در نسخه دیگری باقی می ماند.
علاوه بر این، چنین مشکلی وجود داشت که یک سرویس جدید اضافه شد که کمی با برخی از سرویس های موجود متفاوت بود. و به جای اصلاح یک ماژول موجود، باید یک کپی از آن تهیه کرده و تغییرات لازم را اضافه کنید.
در واقع، Terraform یک زبان واقعی نیست. این یک اعلامیه است. اگر لازم است چیزی را اعلام کنیم، آن را اعلام می کنیم. و این همه کار می کند.
زمانی یکی از همکارانم هنگام بحث در مورد یکی از درخواست های کشش خود گفت که تولید دانه های برف ضروری نیست. تعجب کردم که منظورش چیست. چنین واقعیت علمی وجود دارد که در جهان دو دانه برف یکسان وجود ندارد، همه آنها کمی هستند، اما متفاوت هستند. و به محض شنیدن این موضوع، بلافاصله سنگینی کامل کد Terraform را احساس کردم. زیرا زمانی که لازم بود از نسخه ای به نسخه دیگر منتقل شود، Terraform نیاز به تغییر زنجیره شکسته داشت، یعنی کد دیگر با نسخه بعدی سازگار نبود. و من مجبور شدم یک درخواست کشش کنم که تقریباً نیمی از فایل‌های زیرساخت را پوشش می‌داد تا زیرساخت را به نسخه بعدی Terraform برسانم.
و پس از ظهور چنین دانه‌های برفی، تمام کدهای Terraform که ما آن را به یک توده بزرگ و بزرگ از برف تبدیل کرده بودیم.
برای یک توسعه دهنده خارجی که خارج از عملیات است، برای او اهمیت زیادی ندارد، زیرا او یک درخواست کشش ارائه کرد، منبع او شروع شد. و بس، دغدغه او نیست. و تیم DevOps که مطمئن می شود همه چیز درست است باید همه این تغییرات را انجام دهد. و هزینه این تغییرات با هر دانه برف اضافی بسیار بسیار زیاد شد.
داستانی در مورد نحوه ترسیم یک دانش آموز در یک سمینار با گچ روی تخته سیاه وجود دارد. و معلم تعجب می کند که چگونه توانسته بدون قطب نما اینقدر نرم ترسیم کند. شاگرد پاسخ می دهد: خیلی ساده است، من دو سال در ارتش چرخ گوشت چرخاندم.
و از چهار سالی که در این پروژه بوده‌ام، حدود دو سال است که Terraform را انجام می‌دهم. و البته، من چند ترفند، نکاتی در مورد نحوه ساده کردن کد Terraform، کار با آن مانند یک زبان برنامه نویسی و کاهش بار روی دوش توسعه دهندگانی که باید این کد را به روز نگه دارند، دارم.
اولین چیزی که می خواهم با آن شروع کنم Symlinks است. Terraform کدهای تکراری زیادی دارد. برای مثال، تقریباً در هر نقطه ای که یک زیرساخت ایجاد می کنیم، تماس با یک ارائه دهنده یکسان است. و منطقی است که آن را در یک بابا جداگانه قرار دهیم. و هر جا که ارائه دهنده نیاز به ایجاد Symlinks به این فایل باشد.
به عنوان مثال، شما از نقش فرضی در تولید استفاده می کنید، که به شما امکان می دهد حقوق دسترسی به برخی از حساب های خارجی آمازون را دریافت کنید. و با تغییر یک فایل، همه فایل‌های باقی‌مانده که در درخت منبع هستند، حقوق لازم را خواهند داشت تا Terraform بداند به کدام بخش آمازون دسترسی داشته باشد.
جایی که Symlinks کار نمی کند؟ همانطور که گفتم Terraform فایل های حالت دارد. و خیلی خیلی باحالن اما واقعیت این است که Terraform در همان اول، Backend را مقداردهی اولیه می کند. و او نمی تواند از هیچ متغیری در این پارامترها استفاده کند، آنها همیشه باید در متن نوشته شوند.
و در نتیجه وقتی شخصی منبع جدیدی می سازد، بخشی از کد را از پوشه های دیگر کپی می کند. و او می تواند با کلید یا با سطل اشتباه کند. به عنوان مثال، او یک چیز جعبه شنی را از یک جعبه شنی می‌سازد و سپس آن را در مرحله تولید می‌سازد. و بنابراین ممکن است معلوم شود که سطل در حال تولید از جعبه شنی استفاده می شود. البته آنها به سرعت آن را پیدا خواهند کرد. رفع این مشکل به نحوی امکان پذیر خواهد بود، اما با این وجود اتلاف وقت و تا حدودی منابع است.
بعدش چکار کنیم؟ قبل از کار با Terraform، باید آن را مقداردهی اولیه کنید. در زمان اولیه سازی، Terraform همه پلاگین ها را دانلود می کند. در نقطه ای، آنها از یکپارچه به یک معماری میکروسرویس تر تبدیل شدند. و شما همیشه باید Terraform init را انجام دهید تا همه ماژول ها، همه پلاگین ها را بالا بکشد.
و می توانید از یک اسکریپت پوسته استفاده کنید که اولاً می تواند همه متغیرها را دریافت کند. اسکریپت شل نامحدود است. و در مرحله دوم، راه. اگر همیشه از مسیری که در مخزن است به عنوان کلید پرونده حالت استفاده کنیم، بر این اساس، خطا در اینجا حذف می شود.
داده ها را از کجا دریافت کنیم؟ فایل JSON. Terraform به شما اجازه می دهد تا زیرساخت را نه تنها در hcl (زبان پیکربندی HashiCorp)، بلکه در JSON نیز بنویسید.
خواندن JSON از روی اسکریپت پوسته آسان است. بر این اساس، می توانید یک فایل پیکربندی را با یک سطل در جایی قرار دهید. و از این سطل هم در کد Terraform و هم در اسکریپت پوسته برای مقداردهی اولیه استفاده کنید.
چرا داشتن سطل Terraform مهم است؟ زیرا چیزی به نام فایل های حالت راه دور وجود دارد. یعنی وقتی منبعی را جمع آوری می کنم، تا به آمازون بگویم: «لطفاً نمونه را مطرح کنید»، باید پارامترهای مورد نیاز زیادی را مشخص کنم.
و این شناسه ها در یک پوشه دیگر ذخیره می شوند. و من می توانم آن را بگیرم و بگویم: "Terraform، لطفاً به پرونده ایالتی همان منبع بروید و این شناسه ها را برای من دریافت کنید." و بدین ترتیب نوعی اتحاد بین مناطق یا محیط های مختلف وجود دارد.
همیشه نمی توان از یک فایل حالت راه دور استفاده کرد. به عنوان مثال، شما به صورت دستی یک VPC ایجاد کردید. و کد Terraform که VPC را ایجاد می کند، VPC متفاوتی ایجاد می کند که زمان زیادی طول می کشد و شما باید یکی را به دیگری تنظیم کنید، بنابراین می توانید از ترفند زیر استفاده کنید.
یعنی ماژولی بسازید که همانطور که بود VPC می‌سازد و به شما شناسه می‌دهد، اما در واقع فقط یک فایل با مقادیر کدگذاری شده وجود دارد که می‌توان از آن برای ایجاد همان نمونه استفاده کرد.
همیشه لازم نیست فایل حالت را در فضای ابری ذخیره کنید. به عنوان مثال، هنگام آزمایش ماژول ها، می توانید از مقداردهی اولیه Backend استفاده کنید، زمانی که فایل در زمان آزمایش فقط روی دیسک ذخیره می شود.
حالا کمی در مورد تست. چه چیزی را می توان در Terraform تست کرد؟ احتمالاً خیلی چیزها ممکن است، اما من در مورد این 4 مورد صحبت خواهم کرد.
HashiCorp درک درستی از نحوه قالب بندی کد Terraform دارد. و Terraform fmt به شما امکان می دهد کدی را که ویرایش می کنید مطابق با آن باور فرمت کنید. بر این اساس، آزمایش‌ها باید لزوماً بررسی کنند که آیا قالب‌بندی با آنچه HashiCorp به ارث گذاشته مطابقت دارد یا خیر، تا مجبور نباشید مکان براکت‌ها و غیره را تغییر دهید.
مورد بعدی اعتبارسنجی Terraform است. این کار کمی بیشتر از یک بررسی نحوی انجام می دهد - ala، همه پرانتزها جفت شده اند. اینجا چه چیزی مهم است؟ ما زیرساخت بسیار نازکی داریم. دارای تعداد زیادی پوشه مختلف است. و در هر کدام باید Terraform validate را اجرا کنید.
بر این اساس، برای سرعت بخشیدن به تست، چندین فرآیند را به صورت موازی با استفاده از موازی اجرا می کنیم.
موازی چیز بسیار جالبی است، از آن استفاده کنید.
اما هر بار که Terraform مقداردهی اولیه می‌شود، به HashiCorp می‌رود و می‌پرسد: «آخرین افزونه‌ها چیست؟ و افزونه ای که من در کش دارم - یکی هست یا نه؟ و در هر مرحله از سرعتش کم شد.
اگر Terraform به شما بگوید که پلاگین‌ها کجا هستند، Terraform می‌گوید: «بسیار خوب، این احتمالاً تازه‌ترین چیزی است که وجود دارد. من به جایی نخواهم رفت، بلافاصله اعتبار کد Terraform شما را شروع می کنم."
برای پر کردن پوشه با افزونه های لازم، یک کد Terraform بسیار ساده داریم که فقط باید مقداردهی اولیه شود. البته در اینجا باید تمام ارائه دهندگانی که به نوعی در کد شما مشارکت دارند را مشخص کنید، در غیر این صورت Terraform می گوید: "من هیچ ارائه دهنده ای را نمی شناسم، زیرا در کش نیست."
مورد بعدی طرح Terraform است. همانطور که گفتم، توسعه چرخه ای است. با تغییرات کد میسازیم. و سپس باید دریابید که چه تغییراتی برای زیرساخت برنامه ریزی شده است.
و زمانی که زیرساخت بسیار بسیار بزرگ است، می‌توانید یک ماژول را تغییر دهید، برخی از محیط‌های آزمایشی یا منطقه‌ای خاص را اصلاح کنید، و برخی از همسایه‌ها را بشکنید. بنابراین، باید یک طرح Terraform برای کل زیرساخت ایجاد شود و نشان دهد که چه تغییراتی در نظر گرفته شده است.
شما می توانید آن را به روشی هوشمندانه انجام دهید. به عنوان مثال، ما یک اسکریپت پایتون نوشتیم که وابستگی ها را حل می کند. و بسته به آنچه تغییر کرده است: یک ماژول Terraform یا فقط یک جزء خاص، برای همه پوشه های وابسته برنامه ریزی می کند.
طرح Terraform باید در صورت درخواست انجام شود. حداقل این کاری است که ما انجام می دهیم.
البته آزمایش‌ها برای هر تغییر، برای هر تعهد خوب است، اما برنامه‌ها چیز بسیار پرهزینه‌ای هستند. و ما در درخواست کشش می گوییم: "لطفا برنامه ها را به من بدهید." ربات شروع می شود. و به نظرات ارسال می کند یا تمام طرح هایی که از تغییرات شما انتظار می رود را پیوست می کند.
طرح چیز نسبتاً گرانی است. زمان می برد زیرا Terraform به آمازون می رود و می پرسد: «آیا این نمونه هنوز وجود دارد؟ آیا این مقیاس خودکار دقیقاً همان پارامترها را دارد؟». و برای افزایش سرعت می توانید از پارامتری مانند refresh=false استفاده کنید. این بدان معنی است که Terraform وضعیت S3 را کاهش می دهد. و معتقد است که ایالت دقیقاً با آنچه در آمازون است مطابقت دارد.
چنین طرح Terraform بسیار سریعتر است، اما ایالت باید با زیرساخت شما مطابقت داشته باشد، به عنوان مثال، در جایی، زمانی باید Terraform refresh شروع شود. Terraform Refresh دقیقاً این کار را انجام می دهد، به طوری که وضعیت با آنچه در زیرساخت واقعی است مطابقت دارد.
و در مورد ایمنی باید بگویم. از اینجا باید شروع می شد. جایی که Terraform را اجرا می کنید و Terraform با زیرساخت شما کار می کند، یک آسیب پذیری وجود دارد. یعنی شما در اصل در حال اجرای کد هستید. و اگر درخواست کشش حاوی نوعی کد مخرب باشد، می توان آن را در زیرساختی که دسترسی بیش از حد دارد اجرا کرد. بنابراین، مراقب باشید که در کجا طرح Terraform را راه اندازی می کنید.
مورد بعدی که می خواهم در مورد آن صحبت کنم تست داده های کاربر است.
داده های کاربر چیست؟ در آمازون، هنگامی که یک نمونه ایجاد می کنیم، می توانیم نوعی نامه از نمونه ارسال کنیم - داده های متا. هنگامی که یک نمونه شروع می شود، معمولاً init ابری همیشه در آن نمونه ها وجود دارد. Cloud init این نامه را می خواند و می گوید: "خوب، امروز من یک متعادل کننده بار هستم." و مطابق این دستورات، اعمالی را انجام می دهد.
اما، متأسفانه، وقتی برنامه Terraform را انجام می‌دهیم و Terraform اعمال می‌شود، داده‌های کاربر مانند این مجموعه اعداد به نظر می‌رسند. یعنی فقط برای شما هش می فرستد. و تنها چیزی که می توانید در طرح ببینید این است که آیا تغییراتی وجود خواهد داشت یا هش ثابت می ماند.
و اگر به این توجه نکنید، ممکن است برخی از فایل های متنی مورد ضرب و شتم به آمازون بروند، به زیرساخت واقعی.
همچنین، می توانید نه کل زیرساخت را در حین اجرا، بلکه فقط الگو را مشخص کنید. و در کد بگویید: "Please display this template for me." و در نتیجه، می‌توانید یک پرینت از ظاهر داده‌هایتان در آمازون دریافت کنید.
گزینه دیگر استفاده از یک ماژول برای تولید داده های کاربر است. شما این ماژول را اعمال خواهید کرد. فایل را روی دیسک دریافت کنید. آن را با مرجع مقایسه کنید. و بنابراین، اگر برخی خرداد تصمیم بگیرند کمی داده‌های کاربر را اصلاح کنند، آزمایش‌های شما می‌گویند: "بسیار خوب، اینجا و آنجا تغییراتی وجود دارد - این طبیعی است."
مورد بعدی که می خواهم در مورد آن صحبت کنم Automate Terraform application است.
البته، اعمال Terraform در حالت خودکار به اندازه کافی ترسناک است، زیرا چه کسی می‌داند چه تغییراتی در آنجا رخ داده است و چقدر می‌تواند برای زیرساخت‌های زنده مضر باشد.
برای یک محیط آزمایشی، این همه خوب است. یعنی کاری که یک محیط آزمایشی ایجاد می کند همان چیزی است که همه توسعه دهندگان به آن نیاز دارند. و چنین عبارتی مانند "همه چیز برای من کار کرد" یک الگوی رفتاری خنده دار نیست، بلکه مدرکی است که نشان می دهد شخصی گیج شده است، پشته ای را بالا می برد، آزمایش هایی را روی این پشته انجام می دهد. و مطمئن شد که همه چیز در آنجا خوب است و گفت: "باشه، کدی که منتشر می کنم تست شده است."
در تولید، جعبه شنی و سایر محیط‌هایی که برای کسب‌وکار حیاتی‌تر هستند، استفاده جزئی از برخی منابع بی‌خطر است، زیرا باعث مرگ کسی نمی‌شود. اینها عبارتند از: گروه‌های مقیاس خودکار، گروه‌های امنیتی، نقش‌ها، مسیر53 و لیست می‌تواند بسیار بزرگ باشد. اما مراقب باشید که چه اتفاقی می افتد، گزارش های برنامه های خودکار را بخوانید.
در مواردی که استفاده از آن خطرناک یا ترسناک است، به عنوان مثال، اگر این منابع پایدار هستند، از یک پایگاه داده، گزارش هایی دریافت کنید که تغییرات اعمال نشده در برخی از زیرساخت ها وجود دارد. و مهندس در حال حاضر تحت نظارت مشاغل در حال اجرا برای درخواست یا انجام آن از کنسول خود است.
آمازون چیزی به نام حفاظت از پایان دادن به آن را دارد. و در برخی موارد می تواند از تغییراتی که برای شما لازم نیست محافظت کند. بنابراین Terraform به آمازون رفت و گفت: "من باید این نمونه را بکشم تا نمونه دیگری بسازم". و آمازون می گوید: «ببخشید، امروز نه. ما حفاظت خاتمه داریم.»
و نکته اصلی بهینه سازی کد است. وقتی با کد Terraform کار می کنیم، باید تعداد بسیار زیادی پارامتر را به ماژول منتقل کنیم. اینها پارامترهایی هستند که برای ایجاد نوعی منبع ضروری هستند. و کد به لیست های بزرگی از پارامترها تبدیل می شود که باید از ماژول به ماژول، از ماژول به ماژول دیگر منتقل شوند، به خصوص اگر ماژول ها تو در تو باشند.
و خواندن آن بسیار سخت است. بررسی این موضوع بسیار دشوار است. و اغلب مشخص می شود که برخی از پارامترها در حال بررسی هستند و آنها کاملاً مورد نیاز نیستند. و تعمیر آن بعداً زمان و هزینه دارد.
بنابراین، من پیشنهاد می کنم از چنین چیزی به عنوان یک پارامتر پیچیده که شامل درخت خاصی از مقادیر است استفاده کنید. یعنی به نوعی پوشه نیاز دارید که در آن تمام مقادیری را که دوست دارید در یک نوع محیط داشته باشید داشته باشید.
و با فراخوانی این ماژول، می توانید درختی را دریافت کنید که در یک ماژول مشترک تولید می شود، یعنی در یک ماژول مشترک که برای کل زیرساخت یکسان کار می کند.
در این ماژول، می توانید با استفاده از چنین ویژگی تازه ای در Terraform به عنوان افراد محلی، محاسباتی را انجام دهید. و سپس در یک خروجی، نوعی پارامتر پیچیده را صادر کنید، که ممکن است شامل هش، آرایه و غیره باشد.
در این مورد، تمام بهترین یافته هایی که من به پایان رساندم. و من می خواهم داستانی در مورد کلمب بگویم. هنگامی که او به دنبال پول برای سفر خود برای کشف هند بود (همانطور که در آن زمان فکر می کرد)، هیچ کس او را باور نکرد و معتقد بود که غیرممکن است. سپس فرمود: مواظب باش که تخم مرغ نیفتد. همه بانکداران، افراد بسیار ثروتمند و احتمالاً باهوش، سعی کردند تخم مرغ را به طریقی بگذارند، و همیشه سقوط کرد. سپس کلمب تخم مرغ را گرفت، کمی فشار داد. پوسته مچاله شد و تخم مرغ بی حرکت ماند. گفتند: اوه، این خیلی آسان است! و کلمب پاسخ داد: "بله، خیلی ساده است. و وقتی هند را باز کنم، همه از این مسیر تجاری استفاده خواهند کرد.»
و آنچه من به شما گفتم احتمالاً چیزهای بسیار ساده و پیش پا افتاده ای است. و هنگامی که شما در مورد آنها اطلاع پیدا کردید و شروع به استفاده از آنها کردید، به ترتیب چیزها است. پس استفاده کن و اگر اینها برای شما چیزهای کاملاً عادی هستند، حداقل می دانید چگونه تخم مرغ را طوری قرار دهید که نیفتد.
بیایید خلاصه کنیم:
- سعی کنید از دانه های برف دوری کنید. و هر چه دانه های برف کمتر باشد، به منابع کمتری برای ایجاد هرگونه تغییر در کل زیرساخت بزرگ خود نیاز خواهید داشت.
- تغییر مداوم. یعنی زمانی که تغییراتی در کد ایجاد شده است، باید در اسرع وقت زیرساخت خود را با این تغییرات هماهنگ کنید. نباید شرایطی پیش بیاید که یکی دو یا سه ماه دیگر برای بررسی Elasticsearch بیاید، یک برنامه Terraform ایجاد کند و تغییرات زیادی وجود داشته باشد که او انتظارش را نداشت. و تنظیم مجدد همه چیز به زمان زیادی نیاز دارد.
- تست ها و اتوماسیون. هرچه کد شما بیشتر با تست ها و تراشه ها پوشانده شود، اطمینان بیشتری دارید که همه کارها را درست انجام می دهید. و تحویل خودکار اعتماد به نفس شما را چندین برابر افزایش می دهد.
- کد محیط های آزمایش و تولید باید تقریباً یکسان باشد. از نظر عملی، زیرا در نهایت، تولید کمی متفاوت است و هنوز تفاوت‌های ظریفی وجود خواهد داشت که فراتر از محیط آزمایش است. اما با این وجود، مثبت یا منفی آن را می توان ارائه داد.
- و اگر کدهای Terraform زیادی دارید و به روز نگه داشتن این کد زمان زیادی می برد، پس هیچ وقت دیر نیست که آن را به حالت اول برگردانید.
- زیرساخت های تغییرناپذیر تحویل AMI طبق برنامه
- ساختار مسیر53 زمانی که ورودی های زیادی دارید و می خواهید آنها در یک ترتیب ثابت باشند.
- با محدودیت های نرخ API مبارزه کنید. این زمانی است که آمازون می گوید: "همین است، من نمی توانم هیچ درخواست دیگری را بپذیرم، لطفا صبر کنید." و نیمی از دفتر منتظر است تا بتواند زیرساخت های خود را راه اندازی کند.
- نمونه های نقطه ای آمازون رویداد ارزانی نیست و مکان ها به شما اجازه می دهند تا مقدار زیادی صرفه جویی کنید. و در آنجا می توانید یک گزارش کامل در مورد آن بگویید.
- نقش امنیت و IAM.
- منابع از دست رفته را جستجو کنید، وقتی نمونه هایی با منشأ ناشناخته در آمازون دارید، آنها پول می خورند. حتی اگر نمونه‌ها 100 تا 150 دلار در ماه هزینه داشته باشند، بیش از 1 دلار در سال است. یافتن چنین منابعی یک تجارت پرسود است.
- و مصادیق رزرو شده
این همه برای من است. Terraform خیلی باحاله، ازش استفاده کن. متشکرم!
پرسش
با تشکر از گزارش! شما یک فایل حالت در S3 دارید، اما چگونه می توانید این مشکل را حل کنید که چند نفر می توانند این فایل حالت را بگیرند و سعی کنند آن را مستقر کنند؟
اولاً ما عجله نداریم. ثانیاً، پرچم‌هایی وجود دارد که در آنها گزارش می‌دهیم که در حال کار روی یک قطعه کد هستیم. یعنی با وجود اینکه زیرساخت بسیار بزرگ است، این بدان معنا نیست که شخصی دائماً از چیزی استفاده می کند. و زمانی که یک فاز فعال وجود داشت، این یک مشکل بود، ما فایل‌های حالت را در Git نگه می‌داشتیم. این مهم بود، در غیر این صورت یک نفر یک پرونده حالت ایجاد می‌کرد و ما مجبور بودیم به صورت دستی آنها را در یک پشته جمع‌آوری کنیم تا ادامه دهیم. الان چنین مشکلی وجود ندارد. در کل Terraform این مشکل را حل کرد. و اگر چیزی دائماً در حال تغییر است، می توانید از قفل هایی استفاده کنید که از آنچه شما گفتید جلوگیری می کند.
آیا از منبع باز یا سازمانی استفاده می کنید؟
بدون شرکت، یعنی همه چیزهایی که می توانید بروید و رایگان دانلود کنید.
نام من استانیسلاو است. می خواستم یک اضافه کوچک اضافه کنم. شما در مورد ویژگی آمازون صحبت کردید که به شما امکان می دهد یک نمونه را غیرقابل کشتن کنید. این هم در خود Terraform، در بلوک Life Second، می توانید ممنوعیت تغییر یا ممنوعیت تخریب را تجویز کنید.
از نظر زمان محدود بود. نکته خوبیه
دو تا چیز هم میخواستم بپرسم. ابتدا در مورد آزمایش صحبت کردید. آیا از ابزار تست استفاده کرده اید؟ من در مورد افزونه Test Kitchen شنیدم. شاید چیز دیگری وجود داشته باشد. و من می خواهم در مورد ارزش های محلی بپرسم. آنها اساساً چه تفاوتی با متغیرهای ورودی دارند؟ و چرا نمی توانم چیزی را فقط از طریق Local Values پارامتری کنم؟ من سعی کردم به این موضوع بپردازم، اما به نوعی خودم متوجه نشدم.
می توانیم در پشت این سالن با جزئیات بیشتری صحبت کنیم. ابزارهای تست کاملاً خودساخته ما هستند. چیزی برای آزمایش وجود ندارد. به طور کلی، زمانی که تست‌های خودکار زیرساخت‌ها را در جایی بالا می‌برند، گزینه‌هایی وجود دارد که سالم بودن آن را بررسی کنید و سپس با گزارشی مبنی بر اینکه زیرساخت شما هنوز در وضعیت خوبی قرار دارد، همه چیز را نابود کنید. ما آن را نداریم زیرا پشته های آزمایشی هر روز اجرا می شوند. و بس است. و اگر چیزی شروع به شکستن کند، بدون اینکه ما آن را در جای دیگری بررسی کنیم، شروع به شکستن خواهد کرد.
در مورد ارزش‌های محلی، اجازه دهید گفتگو را خارج از مخاطبان ادامه دهیم.
سلام! با تشکر از گزارش! بسیار آموزنده شما گفتید که تعداد زیادی کد مشابه برای توصیف زیرساخت دارید. آیا به تولید این کد فکر کرده اید؟
سوال عالی، ممنون! نکته این است که وقتی از زیرساخت به عنوان کد استفاده می کنیم، فرض می کنیم که به کد نگاه می کنیم و متوجه می شویم که چه نوع زیرساختی در پشت این کد نهفته است. اگر کد تولید می شود، باید تصور کنیم چه کدی تولید می شود تا بفهمیم چه نوع زیرساختی وجود دارد. یا کد را تولید می کنیم، آن را commit می کنیم و در واقع همان چیزی را می گیریم. بنابراین از راهی که نوشتیم رفتیم، به آن رسیدیم. به علاوه، ژنراتورها کمی دیرتر ظاهر شدند، زمانی که ما شروع به ساخت کردیم. و برای تغییر خیلی دیر شده بود.
آیا نام jsonnet را شنیده اید؟
شماره
ببینید، این واقعا چیز جالبی است. من یک مورد خاص را می بینم که می توانید آن را اعمال کنید و یک ساختار داده ایجاد کنید.
ژنراتورها وقتی خوب هستند، مثل شوخی در مورد ماشین اصلاح. یعنی اولش صورتش فرق می کنه ولی بعد همه یه صورته. ژنراتورها خیلی باحالن اما متاسفانه چهره ما کمی متفاوت است. این مشکل است.
فقط نگاه. متشکرم!
نام من ماکسیم است، من از Sberbank هستم. کمی گفتید که سعی کردید Terraform را به آنالوگ یک زبان برنامه نویسی بیاورید. آیا استفاده از Ansible راحت تر نیست؟
اینها چیزهای بسیار متفاوتی هستند. Ansible می تواند منابع ایجاد کند و Puppet می تواند منابعی را در آمازون ایجاد کند. اما Terraform کاملاً تیز شده است.
آیا شما فقط آمازون دارید؟
اینطور نیست که ما فقط آمازون داریم. ما تقریباً فقط آمازون داریم. اما ویژگی کلیدی این است که Terraform به یاد می آورد. در Ansible، اگر بگویید: "Pick me 5 instance"، آنگاه آن را بالا می برد، و سپس می گویید: "و اکنون به 3 مورد نیاز دارم". و Terraform خواهد گفت: "خوب، من 2 را می کشم" و Ansible خواهد گفت: "خوب، این 3 برای شما است." مجموع 8.
سلام! با تشکر از گزارش شما! شنیدن در مورد Terraform بسیار جالب بود. من فقط می خواهم یک نظر کوچک در مورد این واقعیت داشته باشم که Terraform هنوز نسخه پایداری ندارد، بنابراین بسیار مراقب Terraform باشید.
قاشق خوب برای شام یعنی اگر به راه حلی نیاز دارید، گاهی اوقات چیزی که ناپایدار است و غیره را به تعویق می اندازید، اما کار می کند و به ما کمک می کند.
سوال این است. شما از Remote Backend استفاده می کنید، شما از S 3 استفاده می کنید. چرا از Backend رسمی استفاده نمی کنید؟
رسمی؟
Terraform Cloud.
کی ظاهر شد؟
4 ماه پیش.
اگر 4 سال پیش ظاهر می شد، احتمالاً به سؤال شما پاسخ می دادم.
در حال حاضر یک عملکرد داخلی و قفل وجود دارد و می توانید یک فایل حالت را ذخیره کنید. آن را امتحان کنید. ولی من هم تست نکردم
ما در قطار بزرگی هستیم که با سرعت زیاد در حال حرکت است. و شما نمی توانید فقط چند ماشین را بردارید و بیرون بیندازید.
داشتی از دانه های برف می گفتی چرا از شاخه استفاده نکردی؟ چرا اینطوری نشد؟
ما چنین رویکردی داریم که کل زیرساخت در یک مخزن است. Terraform، Puppet، همه اسکریپت هایی که به نوعی به این مربوط می شوند، همه در یک مخزن هستند. به این ترتیب می توانیم اطمینان حاصل کنیم که تغییرات افزایشی یک به یک آزمایش می شوند. اگر این یک دسته از شاخه ها بود، پس نگهداری چنین پروژه ای تقریبا غیرممکن بود. شش ماه می گذرد و آنقدر از هم دور می شوند که این فقط نوعی مجازات است. این همان چیزی است که من می خواستم قبل از بازسازی مجدد از آن فرار کنم.
یعنی کار نمیکنه؟
اصلا کار نمیکنه
در شاخه، اسلاید پوشه را برش دادم. یعنی اگر برای هر پشته آزمایشی انجام دهید، به عنوان مثال، تیم A پدر خود را دارد، تیم B پدر خود را دارد، این نیز کار نمی کند. ما یک کد محیط آزمایشی یکپارچه ایجاد کردیم که به اندازه کافی انعطاف پذیر بود تا برای همه مناسب باشد. یعنی یک کد سرویس دادیم.
سلام! اسم من یورا است! با تشکر از گزارش! سوال در مورد ماژول ها شما می گویید از ماژول ها استفاده می کنید. اگر تغییراتی در یک ماژول ایجاد شده باشد که با تغییر شخص دیگری سازگار نیست، چگونه مشکل را حل می کنید؟ به نوعی ماژول‌ها را نسخه‌سازی می‌کنید یا تلاش می‌کنید یک اعجوبه را برای برآورده کردن دو نیاز بیاورید؟
این مشکل بزرگ توده برف است. این همان چیزی است که ما از آن رنج می بریم زمانی که برخی تغییرات بی ضرر می تواند بخشی از زیرساخت را بشکند. و تنها پس از مدتی طولانی قابل توجه خواهد بود.
یعنی هنوز قطعی نشده؟
شما ماژول های جهانی می سازید. از دانه های برف دوری کنید. و همه چیز درست خواهد شد. نیمه دوم گزارش در مورد چگونگی اجتناب از آن است.
سلام! با تشکر از گزارش! من می خواهم شفاف سازی کنم. پشت صحنه یک توده بزرگ بود که من برای آن آمدم. چگونه توزیع نقش و عروسک ادغام شده است؟
داده های کاربر
یعنی فقط فایل را تف می کنی و به نوعی روی آن اجرا می کنی؟
داده‌های کاربر یک یادداشت است، یعنی وقتی یک شبیه‌سازی تصویر میسازیم، سپس دیمون از آنجا بلند می‌شود و سعی می‌کند بفهمد او کیست، یادداشتی را می‌خواند که او یک متعادل کننده بار است.
یعنی آیا این یک نوع فرآیند جداگانه است که داده می شود؟
ما اختراعش نکردیم ما از آن استفاده می کنیم.
سلام! من فقط یک سوال در مورد User - data دارم. شما گفتید که آنجا مشکلاتی وجود دارد، ممکن است کسی چیزی را به جای اشتباه بفرستد. آیا راهی برای ذخیره داده های کاربر در همان Git وجود دارد تا همیشه مشخص شود که User-data به چه چیزی اشاره دارد؟
ما داده های کاربر را از الگو تولید می کنیم. یعنی تعداد مشخصی از متغیرها به آنجا متوسل می شوند. و Terraform نتیجه نهایی را ایجاد می کند. بنابراین، نمی‌توانید فقط به الگو نگاه کنید و بگویید چه اتفاقی می‌افتد، زیرا همه مشکلات مربوط به این است که توسعه‌دهنده فکر می‌کند که در حال عبور رشته‌ای در این متغیر است و سپس از یک آرایه استفاده می‌شود. و او - بنگ و من - فلانی، فلانی، خط بعدی، و همه چیز شکست. اگر این یک منبع جدید است و شخصی آن را مطرح می کند، می بیند که چیزی کار نمی کند، به سرعت حل می شود. و اگر این گروه مقیاس خودکار به‌روزرسانی شده باشد، در برخی مواقع نمونه‌های موجود در گروه مقیاس خودکار جایگزین می‌شوند. و کف بزن، چیزی کار نمی کند. درد می کند.
معلوم می شود که تنها راه حل آزمایش است؟
بله، مشکل را می بینید، مراحل تست را در آنجا اضافه می کنید. یعنی خروجی را هم می توان تست کرد. شاید چندان راحت نباشد، اما می توانید برخی از علائم را نیز قرار دهید - بررسی کنید که داده های کاربر در اینجا میخکوب شده باشند.
اسم من تیمور است. بسیار جالب است که گزارش هایی در مورد نحوه سازماندهی صحیح Terraform وجود دارد.
من حتی شروع نکردم
من فکر می کنم که در کنفرانس بعدی، شاید برگزار شود. من یک سوال ساده دارم. چرا به جای استفاده از tfvars، مقدار را در یک ماژول جداگانه کدگذاری می کنید، یعنی یک ماژول با مقادیر بهتر از tfvars است؟
یعنی باید اینجا بنویسم (اسلاید: Production/environment/settings.tf): domain = متغیر، دامنه vpcnetwork، متغیر vpcnetwork و stvars - همان چیزی را دریافت کنید؟
ما دقیقا همین کار را می کنیم. به عنوان مثال به ماژول منبع تنظیم اشاره می کنیم.
در واقع، این چنین tfvars است. Tfvars در یک محیط تست بسیار مفید است. من برای نمونه های بزرگ، برای نمونه های کوچک، tfvars دارم. و من یک فایل را داخل پوشه انداختم. و به چیزی که می خواستم رسیدم وقتی زیرساخت ها را دیدیم، می خواهیم بتوانیم همه چیز را ببینیم و بلافاصله بفهمیم. و بنابراین معلوم می شود که باید اینجا را نگاه کنید، سپس در tfvars نگاه کنید.
معلوم می شود که همه چیز در یک مکان بوده است؟
بله، tfvars زمانی است که شما یک کد دارید. و در چندین مکان مختلف با تفاوت های ظریف مختلف استفاده می شود. بعد تفورها می انداختی و ریزه کاری هایت را می گرفتی. و ما زیرساخت به عنوان کد در خالص ترین شکل آن هستیم. نگاه کرد و فهمید.
سلام! آیا با موقعیت هایی برخورد کرده اید که ارائه دهنده ابر با کاری که شما با Terraform انجام داده اید تداخل داشته باشد؟ فرض کنید ما متا داده ها را ویرایش می کنیم. کلیدهای ssh وجود دارد. و گوگل دائماً متا داده‌ها، کلیدهایش را به آنجا می‌برد. و Terraform همیشه می نویسد که تغییرات دارد. بعد از هر اجرا، حتی اگر چیزی تغییر نکند، همیشه می گوید که الان این فیلد را به روز می کند.
با کلیدها، اما - بله، بخشی از زیرساخت تحت تأثیر چنین چیزی قرار می گیرد، یعنی Terraform نمی تواند چیزی را تغییر دهد. ما هم با دستمان نمی توانیم چیزی را تغییر دهیم. تا زمانی که با آن زندگی کنیم.
یعنی شما به این موضوع برخورد کردید، اما چیزی به ذهنتان نرسید، او چگونه این کار را انجام می دهد و خودش آن را انجام می دهد؟
متاسفانه بله.
سلام! نام من استانیسلاو استارکوف است. ایمیل. en گروه. چگونه مشکل تولید برچسب در ... را حل می کنید، چگونه آن را به داخل منتقل می کنید؟ همانطور که متوجه شدم، از طریق User - data، برای تعیین نام میزبان، Puppet را تحریک کنید؟ و بخش دوم سوال چگونه این مشکل را در SG حل می کنید، یعنی وقتی SG، صد نمونه از یک نوع تولید می کنید، چگونه آنها را به درستی نامگذاری کنید؟
مواردی که برای ما بسیار مهم هستند، آنها را به زیبایی نام می بریم. آنهایی که مورد نیاز نیستند، یک پست نوشته وجود دارد که این یک گروه مقیاس خودکار است. و در تئوری می توان آن را میخ کرد و یک مورد جدید دریافت کرد.
در مورد مشکل برچسب، چنین مشکلی وجود ندارد، اما چنین وظیفه ای وجود دارد. و ما از برچسب ها بسیار بسیار زیاد استفاده می کنیم، زیرا زیرساخت بزرگ و گران است. و ما باید ببینیم که پول برای چه چیزی خرج می شود، بنابراین برچسب ها به ما اجازه می دهند مشخص کنیم که چه چیزی و کجا رفته است. و بر این اساس، جستجوی چیزی در اینجا پول زیادی خرج می شود.
سوال دیگه در مورد چی بود؟
وقتی SG صد نمونه ایجاد می کند، آیا باید به نحوی آنها را متمایز کرد؟
نه، نکن. هر نمونه یک نماینده دارد که به من می گوید مشکلی دارم. اگر نماینده گزارش دهد، آنگاه نماینده در مورد او می‌داند و حداقل آدرس IP او وجود دارد. شما از قبل می توانید اجرا کنید. در مرحله دوم، ما از Consul for Discovery استفاده می کنیم، جایی که Kubernetes وجود ندارد. و Consul همچنین آدرس IP نمونه را نشان می دهد.
یعنی دقیقا IP را هدف گرفته اید نه نام میزبان را؟
پیمایش با نام میزبان غیرممکن است، یعنی تعداد زیادی از آنها وجود دارد. شناسه‌های نمونه وجود دارد - AE و غیره. می‌توانید آن را در جایی پیدا کنید، می‌توانید آن را به جستجو بیندازید.
سلام! متوجه شدم که Terraform چیز خوبی است که برای ابرها طراحی شده است.
نه فقط.
این سوالی است که برای من جالب است. اگر تصمیم دارید، مثلاً، با تمام نمونه‌هایتان به طور دسته جمعی به بره متال بروید؟ آیا مشکلی پیش خواهد آمد؟ یا باز هم باید از محصولات دیگه مثلا همون Ansible که اینجا گفته شد استفاده کنید؟
Ansible کمی در مورد چیز دیگری است. یعنی وقتی نمونه شروع شده است، Ansible در حال اجرا است. و Terraform قبل از شروع نمونه کار می کند. تغییر به فلز برهنه نیست.
الان نه، اما تجارت می آید و می گوید: "بیا."
تغییر به ابر دیگر - بله، اما یک ویژگی کمی متفاوت در اینجا وجود دارد. شما باید کد Terraform را طوری بنویسید که بتوانید با خونریزی کمتری به ابر دیگری بروید.
در ابتدا، وظیفه این بود که کل زیرساخت ما آگنوستیک باشد، یعنی هر ابری باید خوب باشد، اما در مقطعی کسب‌وکار منصرف شد و گفت: «بسیار خوب، در N سال آینده به جایی نخواهیم رسید، می‌توانید از خدمات استفاده کنید. آمازون ".
Terraform به شما اجازه می دهد تا کارهای Front-End را ایجاد کنید، PagerDuty، اسناد داده و غیره را پیکربندی کنید. دنباله های زیادی دارد. او عملاً می تواند کل جهان را کنترل کند.
با تشکر از گزارش! من هم اکنون 4 سال است که Terraform را می چرخم. در مرحله انتقال آرام به Terraform، به زیرساخت، به یک توصیف اعلامی، با وضعیتی مواجه شدیم که شخصی کاری را با دست انجام می‌داد و شما سعی می‌کردید برنامه‌ای بسازید. و من در آنجا با خطا مواجه شدم. چگونه با چنین مشکلاتی برخورد می کنید؟ چگونه منابع از دست رفته را که نشان داده شده بودند پیدا می کنید؟
بیشتر با دست و چشم، اگر چیز عجیبی در گزارش ببینیم، آنگاه آنچه را که در آنجا اتفاق می‌افتد، تحلیل می‌کنیم یا فقط آن را می‌کشیم. به طور کلی، درخواست های کششی یک چیز رایج است.
اگر خطایی وجود داشته باشد، آیا عقب نشینی می کنید؟ آیا این کار را امتحان کرده اید؟
نه، این تصمیم یک فرد در لحظه ای است که مشکل را می بیند.
منبع: www.habr.com