ساخت اکوسیستم پایتون برای توسعه کارآمد و قابل اعتماد | توسط Coinbase | سپتامبر 2022

Tl;dr: این پست وبلاگ توضیح می‌دهد که چگونه یک اکوسیستم پایتون کارآمد و قابل اعتماد را با استفاده از Pants، یک سیستم ساخت منبع باز ایجاد کردیم و چالش مدیریت برنامه‌های Python را در مقیاس بزرگ در Coinbase حل کردیم.

توسط تیم پلتفرم محاسباتی کوین بیس

پایتون یکی از پرکاربردترین زبان های برنامه نویسی برای دانشمندان داده، متخصصان یادگیری ماشین و محققان بلاک چین در کوین بیس است. در چند سال گذشته، شاهد رشد برنامه‌های پایتون بوده‌ایم که هدف آنها حل بسیاری از مشکلات چالش برانگیز در دنیای ارزهای دیجیتال مانند خطوط لوله داده‌های جریان هوا، ابزارهای تجزیه و تحلیل بلاک چین، برنامه‌های کاربردی یادگیری ماشین و بسیاری دیگر است. بر اساس داده های داخلی ما، تعداد برنامه های کاربردی پایتون از سه ماهه سوم سال 2022 تقریباً دو برابر شده است. طبق داده های داخلی ما، امروزه تقریباً 1500 خط لوله پردازش داده و خدمات توسعه یافته با پایتون وجود دارد. تعداد کل ساخت ها در زمان نوشتن حدود 500 در هفته است. ما برنامه‌ای حتی گسترده‌تر را پیش‌بینی می‌کنیم زیرا چارچوب‌های بیشتر پایتون محور (مانند Ray، Modin، DASK و غیره) در اکوسیستم داده ما پذیرفته می‌شوند.

موفقیت مهندسی تا حد زیادی از انتخاب ابزار مناسب ناشی می شود. ساخت یک اکوسیستم پایتون در مقیاس بزرگ برای پشتیبانی از نیازهای مهندسی رو به رشد ما می‌تواند چالش‌هایی را ایجاد کند، از جمله استفاده از یک سیستم ساخت قابل اعتماد، مدیریت وابستگی انعطاف‌پذیر، انتشار سریع نرم‌افزار و بررسی کیفیت کد سازگار. با این حال، این چالش ها را می توان با ادغام Pants، یک سیستم ساخت که توسط آزمایشگاه های Toolchain توسعه داده شده است، در زیرساخت ساخت Coinbase مبارزه کرد. ما به دلایل زیر این را به عنوان سیستم ساخت پایتون انتخاب کردیم:

1. شلوار ارگونومیک و کاربر پسند است،
2. Pants بسیاری از دستورات مربوط به ساخت مانند “test”، “lint”، “fmt”، “typecheck” و “package” را درک می کند.
3. شلوار با استفاده از Python در دنیای واقعی به عنوان یک مورد استفاده درجه یک، از جمله مدیریت وابستگی های شخص ثالث طراحی شده است. در واقع قسمت هایی از خود شلوار به زبان پایتون نوشته شده است (بقیه با Rust نوشته شده است).
4. به لطف استنتاج وابستگی، پیش‌فرض‌های معقول و تولید خودکار فایل‌های BUILD، شلوار نسبت به سایر ابزارها به متادیتا و فایل BUILD کمتری نیاز دارد. Bazel به مقدار زیادی دیگ بخار دست نویس BUILD نیاز دارد.
5. گسترش شلوار آسان است، با یک API افزونه قدرتمند که از کد همگام Python 3 استفاده می کند، به طوری که کاربران می توانند یک جریان کنترل طبیعی در پلاگین های خود داشته باشند.
6. شلوار دارای سیستم OSS واقعی است، جایی که هر سازمانی می تواند نقشی برابر داشته باشد.
7. شلوار منحنی یادگیری ملایمی دارد. نسبت به سایر ابزارها اصطکاک بسیار کمتری دارد. هزینه تعمیر و نگهداری به لطف تجربه نصب با یک کلیک ابزار و فایل های پیکربندی ساده متوسط ​​است.

پایتون یکی از محبوب ترین زبان های برنامه نویسی برای یادگیری ماشین و کاربردهای علم داده است. با این حال، قبل از پذیرش سیستم ساخت اولین پایتون، شلوار، سرمایه گذاری داخلی ما در اکوسیستم پایتون در مقایسه با Golang و Ruby کم بود – انتخاب اصلی برای نوشتن خدمات و برنامه های کاربردی وب در Coinbase.

طبق آمار استفاده از مونورپوی کوین بیس، امروزه پایتون تنها 4 درصد از استفاده را به دلیل عدم پشتیبانی از سیستم ساخت، به خود اختصاص داده است. قبل از سال 2021، بیشتر پروژه‌های پایتون در چندین مخزن بدون زیرساخت ساخت واحد قرار داشتند که منجر به مشکلات زیر می‌شد:

1. چالش های به اشتراک گذاری کد: فرآیند به روز رسانی یک کتابخانه مشترک توسط مهندس پیچیده بود. تغییرات ایجاد شده در کد قبل از اثبات پایداری بیشتر در یک سرور داخلی PyPI منتشر شد. کتابخانه ای که به نسخه جدید ارتقا یافته است، اما آزمایش کافی را انجام نداده است، به طور بالقوه می تواند وابسته ای را که کتابخانه را بدون نسخه پین ​​شده مصرف می کند، از بین ببرد.
2. فقدان فرآیند انتشار ساده: تغییر کد اغلب نیازمند به‌روزرسانی‌ها و انتشارات مخازن پیچیده است. هیچ گردش کار خودکاری برای انجام آزمایش‌های ادغام و مرحله‌بندی برای تغییرات مربوطه وجود نداشت. فقدان قابلیت مشاهده و قابلیت اطمینان منسجم، هزینه مهندسی فوق العاده ای را تحمیل کرد.
3. تجارب توسعه متناقض: تجربه توسعه بسیار متفاوت بود زیرا هر مخزن راه خود را برای راه اندازی محیط مجازی، بررسی کیفیت کد، ساخت و استقرار و غیره داشت.

ما تصمیم گرفتیم PyNest را بسازیم – یک Python “monorepo” جدید برای سازمان داده در Coinbase. هدف ما این نیست که PyNest به عنوان یک monorepo برای کل شرکت استفاده شود، بلکه هدف ما این نیست که این مخزن برای پروژه‌های درون سازمان داده استفاده شود.

1. ایجاد یک مونورپو در سطح شرکت به تیمی از نخبگان نیاز دارد. ما خدمه کافی برای بازتولید داستان های موفقیت مونورپوس در فیس بوک، توییتر و گوگل نداریم.
2. پایتون در درجه اول در سازمان داده در شرکت استفاده می شود. مهم است که محدوده مناسبی را تنظیم کنیم تا بتوانیم روی اولویت های داده تمرکز کنیم بدون اینکه توسط الزامات موردی منحرف شویم. زیرساخت ساخت PyNest می تواند توسط تیم های دیگر برای تسریع مخازن پایتون مورد استفاده مجدد قرار گیرد.
3. برای جلوگیری از وابستگی‌های چرخه‌ای سهوی، مطلوب است که پروژه‌های وابسته به دو طرف (نمودار وابستگی پروژه‌های پلتفرم ML را ببینید) در یک مخزن واحد ادغام کنید.

شکل 1. نمودار وابستگی برای پروژه های پلت فرم یادگیری ماشین (MLP).

1. اگرچه monorepo نوید دنیای جدیدی از بهره وری را داده است، اما ثابت شده است که راه حل بلندمدتی برای Coinbase نیست. گلانگ مونورپو درسی است که پس از یک سال استفاده، مشکلاتی مانند پایگاه کد گسترده، ادغام ناموفق IDE، CI/CD کند، وابستگی های قدیمی و غیره در آن پدیدار شد.
2. پروژه های منبع باز باید در مخازن جداگانه نگهداری شوند.

نمودار زیر معماری مخزن در Coinbase را نشان می دهد، جایی که بلوک های سبز نشان دهنده اکوسیستم جدید پایتون است که ما ساخته ایم. عملکرد بین مخازن با ارائه لایه هایی از جمله مصنوعات کد و رجیستری طرحواره به دست می آید.

شکل 2. معماری مخزن در کوین بیس

# وابستگی شخص ثالث

# third-party dependencies├── 3rdparty│   ├── dependency1│   │   ├── BUILD│   │   ├── requirements.txt│   │   └── resolve1.lock # lockfile│   ││   └── dependency2│   │   ├── BUILD│   │   ├── requirements.txt│   │   └── resolve2.lock...│# shared libraries├── lib│# top level project folders├── project1 # project name│    ├── src│    │    └── python│    │         ├── databricks│    │         │    ├── BUILD│    │         │    ├── OWNERS│    │         │    ├── gateway.py│    │         │    ...│    │         └── notebook│    │              ├── BUILD│    │              ├── OWNERS│    │              ├── etl_job.py│    │              ...│    └── test│         └── python│              ├── databricks│              │    ├── BUILD│              │    ├── gateway_test.py│              │    ...│              └── notebook│                   ├── BUILD│                   ├── etl_job_test.py│                   ...├── project2...│# Docker files├── dockerfiles│# tools for lint, formatting, etc.├── tools│# Buildkite CI workflow├── .buildkite│    ├── pipeline.yml│    └── hooks│# Pants library├── pants├── pants.toml└── pants.ci.toml

شکل 3. ساختار مخزن Pynest

در زیر لیستی از عناصر اصلی مخزن و توضیحات آنها آمده است.

1. شخص ثالث

وابستگی های شخص ثالث در این پوشه قرار می گیرند. Pants فایل های requirement.txt را تجزیه می کند و به طور خودکار هدف “python_requirement” را برای هر یک از وابستگی ها ایجاد می کند. چندین نسخه از وابستگی یکسان توسط ویژگی lockfiles چندگانه Pants پشتیبانی می شود. این ویژگی این امکان را برای پروژه‌ها فراهم می‌کند که در وابستگی‌های مستقیم یا گذرا تضاد داشته باشند. شلوار فایل‌های قفلی تولید می‌کند تا هر وابستگی را پین کند و از ساخت قابل تکرار اطمینان حاصل کند. توضیحات بیشتر در مورد قفل چندگانه شلوار در قسمت مدیریت وابستگی است.

2. لیب

کتابخانه های مشترک قابل دسترسی برای همه پروژه ها. پروژه های داخل PyNest می توانند به طور مستقیم کد منبع را وارد کنند. برای پروژه‌های خارج از PyNest، کتابخانه‌ها می‌توانند از طریق پیپ نصب فایل‌های چرخ از یک سرور داخلی PyPI دسترسی داشته باشند.

3. پوشه های پروژه

پروژه های فردی در این پوشه زندگی می کنند. مسیر پوشه به صورت «{project_name}/{src or test}/python/{namespace}» فرمت شده است. ریشه منبع به صورت “src/python” یا “test/python” پیکربندی شده است و فضای نام زیر برای جداسازی ماژول ها استفاده می شود.

4. فایل های صاحب کد

فایل های مالک کد (OWNERS) به پوشه ها اضافه می شوند تا افراد یا تیم هایی که مسئول کد در درخت پوشه هستند، تعریف شوند. گردش کار CI یک اسکریپت را فراخوانی می کند تا همه فایل های OWNERS را در یک فایل CODEOWNERS تحت “.github/” کامپایل کند. قانون تأیید مالک کد مستلزم آن است که همه درخواست‌های کششی حداقل یک تأیید از گروه مالکان کد قبل از ادغام داشته باشند.

5. ابزار

پوشه Tools حاوی فایل های پیکربندی برای ابزارهای کیفیت کد، به عنوان مثال flake8، black، isort، mypy، و غیره است.

6. گردش کار Buildkite

Coinbase از Buildkite به عنوان پلتفرم CI استفاده می کند. گردش کار Buildkite و تعاریف هوک در این پوشه تعریف شده است. گردش کار CI مراحلی مانند

• بررسی کنید که آیا فایل‌های قفل وابستگی نیاز به به‌روزرسانی دارند یا خیر.
• ابزارهای لینت و کیفیت کد را اجرا کنید.
• کد منبع و تصاویر داکر را بسازید.
• تست های واحد و ادغام را اجرا می کند.
• گزارش هایی از پوشش های کد ایجاد می کند.

7. Dockerfiles

Dockerfiles در این پوشه تعریف شده است. تصاویر داکر توسط گردش کار CI ساخته شده و توسط Codeflow – یک پلت فرم استقرار داخلی در Coinbase – مستقر شده اند.

8. کتابخانه های شلوار

این پوشه حاوی اسکریپت Pants و فایل های پیکربندی (pants.toml، pants.ci.toml) است.

این مقاله نحوه ساخت PyNest را با استفاده از سیستم ساخت شلوار توضیح می دهد. در پست بعدی وبلاگ خود، مدیریت وابستگی و CI/CD را توضیح خواهیم داد.