Flowpipe به شما این امکان را می دهد که با استفاده از زبان پیکربندی استاندارد devops، HCL، گردش های کاری پیچیده و بسیار موازی را به سبک اعلانی ایجاد کنید.
- کد را به من نشان دهید!
- چرا زبان پیکربندی HashiCorp؟
- زمانبندیها، رویدادها و محرکها
- منطقه Goldilocks
اگر زیرساخت خود را به عنوان کد تعریف کنید، آیا اتوماسیون گردش کار شما نباید از همان رویکرد به عنوان کد استفاده کند؟ Flowpipe اینگونه کار می کند. گردش کار را با HCL (زبان پیکربندی HashiCorp) تعریف کنید، سپس آنها را با استفاده از یک باینری واحد که به صورت محلی مستقر میکنید، اجرا کنید. ابر یا در هر خط لوله CI/CD. Flowpipe شامل همان اجزای معماری است که در هر ابزار گردش کار پیدا خواهید کرد: خطوط لوله، مراحل، تریگرها، جریان کنترل. و با هر چیزی که از ابزاری در این دسته انتظار دارید یکپارچه می شود.
اما این ClickOps نیست. شما از ابزار نمودار برای ایجاد یکپارچگی استفاده نمی کنید. تعاریف خط لوله، مصنوعات کدی هستند که در مخازن به عنوان شهروندان درجه یک اکوسیستم نرم افزار مدرن زندگی می کنند: نسخه کنترل شده و مشارکتی.
این خطوط لوله میتوانند با استفاده از طیف وسیعی از روشها، جریانهای کاری را تنظیم کنند. آیا باید مشکلات باز را در GitHub ردیابی کنید و سپس به Slack اطلاع دهید؟ بیش از یک راه برای جمع آوری داده های GitHub که به Slack ارسال می کنید وجود دارد:
- در یک مرحله خط لوله. از خط لوله
list_issues
کتابخانه GitHub استفاده کنید، که یک مرحله http را در بر می گیرد که GitHub API را فراخوانی می کند. - در یک مرحله پرس و جو. از پلاگین GitHub Steampipe برای پرس و جو برای مسائل باز موجود در مخزن استفاده کنید.
- در یک مرحله عملکرد. برای فراخوانی GitHub API، یک تابع سازگار با AWS-Lambda، در Python یا JavaScript بنویسید.
- در یک مرحله کانتینر، GitHub CLI را در یک ظرف بسته بندی کنید و اجرا کنید به این ترتیب
لیست مشکل
.
چرا این همه انتخاب؟ شعار قدیمی پرل “بیش از یک راه برای انجام آن وجود دارد” در اینجا نیز کاربرد دارد. Flowpipe تجسم مدرن “نوار برای اینترنت” است: یک کیت انعطاف پذیر پر از ابزارهای مفید که به خوبی با هم کار می کنند. برای هر یکپارچگی، مناسبترینها را در آن زمینه انتخاب کنید، یا داراییهای موجود را تحت تأثیر قرار میدهد، یا راحتتر است. شما هرگز بلاک نمی شوید همیشه راهی برای انجام کار وجود دارد که در یک چشم انداز پیچیده از ابرها و خدمات متنوع و به هم پیوسته حرکت می کنید.
کد را به من نشان دهید!
در اینجا چهار راه برای جمع آوری اطلاعات در مورد مشکلات GitHub وجود دارد.
مشکلات GitHub را با استفاده از کتابخانههای GitHub و Slack Flowpipe فهرست کنید
Flowpipe mods خطوط لوله قابل استفاده مجدد را ارائه می دهد. در این مورد، مدهای کتابخانه ای با پشتیبانی از هر دو عملیات مورد نیاز وجود دارد: فهرست کردن مشکلات GitHub، اطلاع رسانی Slack. بنابراین ما فقط می توانیم از آن کتابخانه ها در یک جفت مرحله خط لوله استفاده کنیم.
pipeline "list_open_issues_and_notify_slack" { step "pipeline" "list_issues" { pipeline = github.pipeline.list_issues # use the github library mod args = { issue_state: "OPEN" repository_owner: "turbot" repository_name: "steampipe" } } step "pipeline" "notify_slack" { pipeline = slack.pipeline.post_message # use the github slack mod args = { token = var.slack_token channel = var.slack_channel message = step.pipeline.list_issues.value } }
اسناد GitHub و Slack خطوط لوله موجود و برای هر خط لوله، پارامترها. استفاده از مدهای منتشر شده Flowpipe ساده است، و به همان اندازه ساده است که خودتان ایجاد و استفاده کنید.
مشکلات GitHub را با استفاده از افزونه GitHub Steampipe فهرست کنید
Flowpipe به Steampipe نیاز ندارد اما با خوشحالی آن را در آغوش میکشد. اگر بتوانید از هر دو با هم استفاده کنید، قدرت فوق العاده ای به دست خواهید آورد. پلاگین GitHub تنها یکی از بسیاری بستهبندیها برای اکوسیستم رو به رشد منابع داده است که هر کدام به صورت جدولهایی که میتوانید مدلسازی شدهاند. پرس و جو با SQL در مرحله پرس و جو.
pipeline "list_open_issues_and_notify_slack" { step "query" "query_list_issues" { connection_string = "postgres://steampipe@localhost:9193/steampipe" sql = <<EOQ select * from github_issue where repository_full_name = 'turbot/steampipe' and state = 'OPEN' EOQ } step "pipeline" "notify_slack" { # use the library mod as above, or another method } }
تنها چیزی که در اینجا نیاز دارید یک رشته اتصال است. اگر به Steampipe متصل شوید، میتوانید به اکوسیستم پلاگین آن ضربه بزنید، اما اگر دادههایی که دنبال میکنید در پایگاه داده دیگری زندگی میکنند، میتوانید از SQL برای جستجوی آن از آنجا استفاده کنید.
مشکلات GitHub را با استفاده از یک تابع سازگار با Lambda فهرست کنید
اگر نه یک مد کتابخانه و نه افزونه Steampipe برای مورد استفاده شما وجود داشته باشد، چه؟ گزینه دیگر: فراخوانی یک تابع در مرحله تابع.
pipeline "list_open_issues_and_notify_slack" { step "function" "list_issues" { src = "./functions" runtime = "python:3.10" handler = "list_issues.handler" event = { owner = "turbot" repo = "steampipe" } }
این تابع است.
def handler(event, context): owner = event['owner'] repo = event['repo'] url = f"https://api.github.com/repos/{owner}/{repo}/issues?state=closed" response = requests.get(url) return { 'issues': response.json() }
این توابع، که می توانید در پایتون یا جاوا اسکریپت بنویسید، با توابع AWS Lambda سازگار هستند: رویداد محور، بدون حالت، کوتاه مدت. و در مقایسه با توابع AWS Lambda، نوشتن و آزمایش آنها بسیار ساده تر است. حتی میتوانید عملکردهای خود را به صورت زنده ویرایش کنید، زیرا وقتی تغییراتی ایجاد میکنید، Flowpipe به طور خودکار آنها را شناسایی و اعمال میکند.
مشکلات GitHub را با استفاده از GitHub CLI فهرست کنید
واسط های خط فرمان ابزارهای اساسی برای ادغام DevOps هستند. می توانید یک CLI را در یک ظرف بسته بندی کنید و از آن در مرحله ظرف استفاده کنید.
pipeline "list_open_issues_and_notify_slack" { step "container" "list_issues" { image = "my-gh-image" cmd = ["/container-list-issues.sh"] env = { GITHUB_TOKEN = var.access_token GH_COMMAND = var.gh_command } }
این احتمالاً در این مورد بیش از حد است، اما توانایی استفاده از دستورات کانتینری به این روش حداکثر انعطاف پذیری و قابلیت حمل را تضمین می کند.
چرا زبان پیکربندی HashiCorp؟
زبان پیکربندی HashCorp (HCL) اول از همه برای متخصصان توسعه دهنده که از آن برای بیان تنظیمات Terraform استفاده می کنند آشنا است. اما معلوم می شود که این زبان برای گردش کار نیز مناسب است. نمودار غیر چرخه ای جهت دار (DAG) در هسته مدل اجرای خود، بر خلاف بسیاری از زبان های برنامه نویسی که چنین وابستگی هایی باید به صراحت مدیریت شوند، ترتیب عملیات ها را بر اساس وابستگی به منابع تعیین می کند.
اگر مرحله دوم در یک گردش کار به خروجی مرحله اول اشاره دارد، Flowpipe به طور ضمنی مراحل را ترتیب می دهد. همزمانی نیز ضمنی است. مراحل گردش کار که به مراحل دیگر بستگی ندارند به طور خودکار به صورت موازی اجرا می شوند، نیازی به نحو خاصی نیست. بنابراین میتوانید گردشهای کاری پیچیده و بسیار موازی را در سبکی بیانی ایجاد کنید که خواندن و نوشتن آسان است. برای مثال، در اینجا مرحلهای وجود دارد که روی فهرستی از کاربران تکرار میشود و از یک http استفاده میکند. مرحله فراخوانی یک API برای هر کاربر.
step "http" "add_a_user" { for_each = ["Jerry", "Elaine", "Newman"] url = "https://myapi.local/api/v1/user" method = "post" request_body = jsonencode({ user_name = "${each.value}" }) }
از آنجایی که کارها همیشه طبق برنامه پیش نمی روند، سبک بیانی Flowpipe به مدیریت خطا گسترش می یابد و دوباره تلاش می کند.
step "http" "my_request" { url = "https://myapi.local/subscribe" method = "post" body = jsonencode({ name = param.subscriber }) retry { max_attempts = 5 strategy = "exponential" min_interval = 100 max_interval = 10000 } }
معمولاً باید نتایج یک مرحله از یک خط لوله را باز کنید، سپس دادهها را برای انتقال به مرحله بعدی تغییر دهید. در میان توابع HCL سازگار با Terraform پشتیبانی شده توسط Flowpipe، توابع مجموعه که با لیست ها و نقشه ها کار می کنند.
pipeline "get_astronauts" { step "http" "whos_in_space" { url = "http://api.open-notify.org/astros" method = "get" } output "method_1" { value = [for o in step.http.whos_in_space.response_body.people: po.name] } output "method_2" { value = step.http.whos_in_space.response_body.people[*].name } }
در اینجا خروجی فرمان flowpipe pipeline run get_astronauts
است.
این دو روش روشهای معادلی برای تکرار بر روی فهرست نقشههای بازگشتی از API و استخراج فیلد name
از هر کدام هستند. روش اول از عبارت همه کاره for استفاده می کند که می تواند با لیست ها، مجموعه ها، تاپل ها کار کند. ، نقشه ها و اشیاء. روش دوم با استفاده از عبارت splat نتیجه یکسانی می دهد، که می تواند دسترسی به فیلدهای درون عناصر لیست ها، مجموعه ها و تاپل ها.
زمانبندیها، رویدادها، و محرکها
همانند سایر موتورهای گردش کار، میتوانید یک خط لوله Flowpipe را بر اساس یک برنامه زمانبندی تعریفشده راهاندازی کنید.
trigger "schedule" "daily_3pm" { schedule = "* 15 * * *" pipeline = pipeline.daily_task }
اما شما همچنین میخواهید فوراً به رویدادهایی مانند فشار کد، تغییر زیرساخت یا پیامهای Slack واکنش نشان دهید. بنابراین Flowpipe یک محرک مبتنی بر HTTP برای واکنش به یک وبکهک ورودی با اجرای یک خط لوله ارائه میکند.
trigger "http" "my_webhook" { pipeline = pipeline.my_pipeline args = { event = self.request_body } }
برای استفاده از محرکها، Flowpipe را در حالت سرور اجرا کنید.
منطقه Goldilocks
Flowpipe بین ابزارهایی مانند Zapier یا IFTTT که به کد کمی یا بدون نیاز به کد برای چیزهای ساده نیاز دارند و ابزارهایی مانند N8N یا Windmill که میتوانند کارهای پیچیده انجام دهند اما به کد زیادی نیاز دارند، حد وسطی را اشغال میکند. شما خطوط لوله، مراحل و تریگرها را در زبان پیکربندی استاندارد devops بیان می کنید: HCL. در صورت نیاز، آن کد را با SQL، یا پایتون، یا جاوا اسکریپت، یا bash یا هر چیزی که می توانید در یک ظرف بسته بندی کنید، تقویت کنید.
شما همه آن منابع را با استفاده از یک مدل اجرای مشترک تعبیه شده در یک باینری منفرد که به عنوان یک CLI اجرا میشود، و/یا به عنوان سروری که وظایف را زمانبندی میکند و به وبقلابها گوش میدهد، هماهنگ میکنید. در هر صورت می توانید آن باینری واحد را به صورت محلی اجرا کنید یا آن را در هر خط لوله ابری یا CI/CD مستقر کنید.
برای شروع، ابزار را دانلود کنید، مدهای کتابخانه و نمونهها< /a>، و آموزش را اجرا کنید.
آیا سبک پیشفرض کد اعلامی Flowpipe با اسکریپتهای devops طنینانداز خواهد شد؟ آن را امتحان کنید و به ما اطلاع دهید چگونه پیش میرود. و اگر مایلید در موتور دارای مجوز AGPL یا مدهای دارای مجوز آپاچی، ما همیشه از دریافت درخواستهای کشش خوشحالیم!
پست های مرتبط
Flowpipe: یک موتور گردش کار برای توسعه دهنده اسکریپت
Flowpipe: یک موتور گردش کار برای توسعه دهنده اسکریپت
Flowpipe: یک موتور گردش کار برای توسعه دهنده اسکریپت