مطالعه بیشتر

گزینه‌هایی برای spin up کردن محیط‌های dev، staging، یا test.

آموزش: محیط‌های چندگانه

گزینه‌هایی برای spin up کردن محیط‌های dev، staging، یا test.

وقتی شروع به اجرای متابیس در production می‌کنید، احتمالاً می‌خواهید تست و توسعه خود را در محیط‌های جداگانه انجام دهید. برای بیشتر تیم‌ها، این به معنای ایجاد یک کپی از برخی (یا همه) نمودارها و داشبوردها در production، ایجاد تغییرات در آن کپی‌ها، و سپس به طور اختیاری push کردن آن تغییرات به production است.

برای تیم‌هایی که می‌خواهند تغییرات برنامه‌نویسی به بسیاری از آیتم‌ها یا تنظیمات متابیس به طور همزمان ایجاد کنند، بهتر است یک instance برای هر محیط تنظیم کنید. همچنین می‌توانید محیط‌های dev و prod را برای نگهداری داشبورد با ایجاد یک مجموعه برای هر محیط تقلید کنید.

یک instance برای هر محیط

برای تنظیم یک instance برای هر یک از محیط‌های خود، نیاز به یک طرح Pro یا Enterprise self-hosted دارید. چون طرح‌های Pro و Enterprise self-hosted به راحتی به ازای هر حساب شارژ می‌کنند، می‌توانید به تعداد دلخواه instanceهای متابیس را spin up کنید. فقط به خاطر داشته باشید که برای تعداد کل کاربران در همه متابیس‌های خود پرداخت می‌کنید، پس فقط حداقل تعداد کاربران مورد نیاز برای تنظیم instanceهای staging یا dev خود را اضافه کنید (مثلاً، یک کاربر تست واحد در یک گروه برای تست مجوزها تنظیم کنید، به جای افزودن همه کاربران از instance prod خود).

برای راه‌اندازی یک محیط جدید بر اساس متابیس production خود، از ویژگی serialization متابیس برای ایجاد یک export از نمودارها، داشبوردها، و تنظیمات خود استفاده خواهید کرد. همچنین می‌توانید فایل‌های YAML export را قبل از import کردن آن به یک instance staging جدید متابیس ویرایش کنید. به عنوان مثال، می‌توانید مجموعه‌ای از قالب‌های داشبورد با برندینگ ایجاد کنید که می‌تواند برای پر کردن هر محیط جدید استفاده شود.

وقتی زمان push کردن تغییرات از staging به prod می‌رسد، تیم شما از همان فرآیند serialization برای export از staging و import آن به prod استفاده خواهد کرد. همچنین می‌توانید تست‌های integration خود را تنظیم کنید تا از import کردن هر چیزی که ممکن است instance production شما را بشکند جلوگیری کنید.

مثال: ایجاد یک instance staging self-hosted

بگویید instance production متابیس شما روی Docker یا مشابه آن اجرا می‌شود:

یک backup از پایگاه داده برنامه استفاده شده برای instance prod خود ایجاد کنید.
یک container جدید به نام staging ایجاد کنید.

با استفاده از متغیرهای محیطی مناسب به پایگاه داده برنامه prod خود متصل شوید.
کلید لایسنس خود را با استفاده از MB_PREMIUM_EMBEDDING_TOKEN اضافه کنید.
برچسب نسخه (مثل metabase/metabase-enterprise:v1.56.12) که با instance prod شما match می‌کند را شامل کنید.

از container staging، یک متابیس تازه با تنظیمات زیر شروع کنید:
وقتی متابیس در container staging در حال اجرا است، دستور serialization export را اجرا کنید.
export را به هر object storage که می‌خواهید persist کنید.
اختیاری: فایل‌های YAML export را ویرایش کنید. به عنوان مثال، می‌توانید یک اسکریپت اجرا کنید تا ID = 1 را با ID = 2 جایگزین کند.
container staging را restart کنید.
از container staging، یک پایگاه داده برنامه تازه ایجاد کنید.

با استفاده از متغیرهای محیطی مناسب به پایگاه داده برنامه جدید متصل شوید.
کلید لایسنس خود را با استفاده از MB_PREMIUM_EMBEDDING_TOKEN اضافه کنید.
برچسب نسخه (مثل metabase/metabase-enterprise:v1.56.12) که با instance prod شما match می‌کند را شامل کنید.

متابیس را با دستور serialization import شروع کنید:

مراحل دقیق به deployment شما بستگی دارد. اگر گیر کردید، همیشه می‌توانید از یکی از مهندسان موفقیت ما بپرسید!

یک مجموعه برای هر محیط

برای مدیریت تغییرات به داشبوردهای متابیس بدون serialization، می‌توانید از مجموعه‌ها، مجوزهای مجموعه، و تاریخچه استفاده کنید.

مثال: ایجاد مجموعه‌های Prod و Dev

در اینجا مثالی از نحوه تنظیم یک "محیط" برای هر مجموعه:

دو مجموعه به نام‌های Prod و Dev ایجاد کنید.
دو گروه به نام‌های End Users و Developers ایجاد کنید.

Developers می‌توانند مجموعه‌های Prod و Dev را Curate کنند.
End Users می‌توانند مجموعه Prod را View کنند.

مجوزهای مجموعه را برای هر گروه تنظیم کنید:

Developers دسترسی Query builder and native به جداول یا پایگاه‌های داده استفاده شده در مجموعه‌های Dev و Prod دریافت می‌کنند.
End Users امنیت ردیف و ستون برای جداول یا پایگاه‌های داده استفاده شده در مجموعه Prod تنظیم شده است.

اختیاری: مجوزهای داده را برای هر گروه تنظیم کنید. به عنوان مثال:

اعضای گروه Developers می‌توانند آیتم‌ها را بین مجموعه‌های Prod و Dev کپی و انتقال دهند تا تغییرات را بدون افشای کار در حال انجام ایجاد کنند. مشتریان همچنین می‌توانند تغییرات را با استفاده از تاریخچه یک آیتم مشاهده و revert کنند.