کلیک ، کپی و چسباندن. این یک رویکرد برای استقرار برنامه های شما در Kubernetes است. هرکسی که بیش از 5 دقیقه با Kubernetes کار کرده باشد می داند که این دستور العمل تکرارپذیری و اعتماد به نفس در تنظیم شما نیست. خبر خوب این است که شما هنگام مقابله با این مشکل گزینه هایی دارید. گزینه ای که من در زیر ارائه می دهم استفاده از Helm است.
Helm خود را به این شرح می دهد:
مدیر بسته برای Kubernetes – https://helm.sh
اما این دقیقاً برای توسعه دهنده یا مدیر خوشه Kubernetes چه معنی دارد؟ و چگونه می توان یک API را به منابع مشترک Kubernetes مانند خدمات ، استقرار ، ماکت و سایر موارد بسته بندی کرد؟ پروژه مثال در زیر برخی از پاسخ های این سؤالات را بررسی کرده و یک نقطه شروع عالی برای ادامه آن ارائه می دهد.
این چه مشکلی حل می شود؟
با بازگشت به استقرار برنامه API در یک خوشه ، تعدادی از منابع مختلف برای تحقق این امر لازم است. برای یک مورد استفاده ساده ، من به موارد زیر احتیاج دارم:
- خدمت
- ماکت
- نقشه پیکربندی
- اعزام
این چهار منبع نقطه شروع را برای من فراهم می کند تا از آن استفاده کنم اما حداقل ، من خدمات خود را در حال اجرا و خدمت به ترافیک هستم. مطمئناً می توانم تمام مقادیر خود را مستقیماً در تعاریف منابع خود کد کنم. باز هم ، این یک رویکرد است. اما دقایقی که من نیاز به داشتن یک محیط دیگر ، مانند QA ، می خواهم به کپی کردن کارهایم و 2 نسخه از منابع کامل خود بپردازم. این امر زباله و فرصت ها را برای خطاها معرفی می کند.
کاری که Helm به من اجازه می دهد انجام دهم این است که الگوئی هایی را تعریف کنم که من می توانم مقادیر را در آن تهیه کنم. به این معنی که من در هر محیط فایلهای ارزش خواهم داشت اما فقط یک نسخه از مجموعه واقعی منابع مورد نیاز خود را دارم. زباله کمتر فضای کمتری برای خطا. و یک نسخه از حقیقت.
نمونه برنامه نویسی
این را مقدمه ای برای HELM با یک پروژه خاص در نظر بگیرید. من به هیچ وجه سعی نمی کنم همه چیز را در مورد Helm نشان دهم یا در مورد 4 منبع که می خواهم با آنها کار کنم ، به مشخصات خود نشان دهم. هدف من این است که شما در ساخت منابع Kubernetes در معرض این رویکرد قرار بگیرید و احساس راحتی بیشتری برای امتحان کردن کلاهبرداری در پروژه های خود داشته باشید.
رمز کار
مثل همیشه ، در پایان این مقاله پیوندی به مخزن GitHub وجود خواهد داشت و اگر می خواهید کارها را نیز اجرا کنید ، این تصویر Docker را در مخزن عمومی AWS ECR منتشر کرده ام. اجرای آنچه در پشت آن مخزن است ، یک برنامه زنگ زدگی است که یک سرور Axum را در حال گوش دادن به خدمت به دو مسیر است. / وت /second
use axum::{routing::get, Router};
async fn root_handler() -> &'static str {
tracing::info!("Hello, Axum!");
"Hello, Axum!"
}
async fn second_handler() -> &'static str {
tracing::info!("Second handler");
"Second handler"
}
#[tokio::main]
async fn main() {
let bind_address = std::env::var("BIND_ADDRESS").expect("BIND_ADDRESS is required");
let app = Router::new()
.route("https://dev.to/", get(root_handler))
.route("/second", get(second_handler));
let listener = tokio::net::TcpListener::bind(bind_address.clone())
.await
.unwrap();
tracing::info!("Up and running ... listening on {}", bind_address);
axum::serve(listener, app).await.unwrap();
}
تور
من قبلاً در مورد ترجیح خود برای Minikube برای اجرای خوشه های خود در محلی نوشتم و قصد دارم همین کار را در اینجا انجام دهم. من عاشق اجرای سرویس AWS elastic Kubernetes هستم اما هزینه خوشه و گره ها فقط خود را به آنچه می خواستم با این مثال انجام دهم وام نمی دهد. اگر قبلاً Minikube را اجرا نکرده اید ، ابتدا آن مقاله را بخوانید و وقتی آماده هستید ، به اینجا بروید.
اولین قدم در فرآیند در اینجا نصب کلاه ایمنی است. بسته به سیستم شما ، گزینه های زیادی برای تحقق این امر وجود دارد. با این مرحله از راه خارج ، وقت آن است که نمودارها را صحبت کنیم.
نمودار
کلاه ایمنی خود را در اطراف مفهوم یک نمودار قرار می دهد. این را به عنوان تعریف برنامه خود فکر کنید. هرچه در پروژه شما تعریف شده باشد ، زیر چتر یک نمودار اتفاق می افتد. هنگام ایجاد نمودار با helm create my-chart، با ساختاری که به نظر می رسد با شما رفتار می شود:
my-chart/
Chart.yaml
values.yaml
charts/
در Chart.yaml پرونده ای که ایجاد می شود در زیر است.
apiVersion: v2
name: chart
description: A Helm chart for Kubernetes
# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
type: application
# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
# Versions are expected to follow Semantic Versioning (https://semver.org/)
version: 0.1.0
# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application. Versions are not expected to
# follow Semantic Versioning. They should reflect the version the application is using.
# It is recommended to use it with quotes.
appVersion: "1.16.0"
الگوهای
قالب ها در مرکز آنچه من در مورد ساخت ساختمان قرار دارم قرار دارند. از الگوهای به عنوان منبع Kubernetes فکر کنید زیرا این همان چیزی است که آنها هستند. اما به جای اینکه مقادیر پر شده باشد ، می خواهم از زبان الگوی GO استفاده کنم تا صاحبخانه ها را که از پرونده مقادیر پر شده است ، استفاده کنم.
این پرونده پیکربندی را بگیرید. من بریس های فرفری دوتایی دارم {{ }} که به هلم می گوید این جایی است که باید یک مقدار درج شود. و سپس من از اشیاء کلاه داخلی مانند استفاده می کنم Release وت Valuesبشر اشیاء داخلی چگونه با پر کردن مقادیر موجود در قالب های خود کار می کنید.
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
BIND_ADDRESS: {{ .Values.container.environmentVariables.bindAddress | quote }}
RUST_LOG: {{ .Values.container.environmentVariables.rustLog | quote }}
همچنین توجه کنید که من از a استفاده می کنم | بعد از من .Values و ارسال آن به quote عملکرد. Helm از لوله کشی پشتیبانی می کند که می تواند خروجی های زنجیره ای را به هم زنجیر کند تا مقدار فایل مورد نظر خود را ایجاد کند. و در این حالت ، من ارزش خود را به quote عملکردی که قرار خواهد داد " " در اطراف خروجی من
کاوش در منبع استقرار کمی بیشتر از قدرت آنچه را که می توانم با الگوها پر کنم نشان می دهد.
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ .Release.Name}}-deployment
labels:
app: rust-service-1
spec:
replicas: {{ .Values.replicas }}
selector:
matchLabels:
app: rust-service-1
template:
metadata:
labels:
app: rust-service-1
spec:
containers:
- name: web-api
image: {{ .Values.container.image.path }}
ports:
- containerPort: {{ .Values.container.containerPorts.targetPort }}
name: web-port
protocol: {{ .Values.container.containerPorts.protocol }}
envFrom:
- configMapRef:
name: {{ .Release.Name }}-configmap
زبان قالب بندی بسیار قدرتمند است. موارد فوق فقط یک مثال اساسی است ، اما من می توانم حلقه ها و شرط ها را برای تغییر جریان آنچه تولید می شود ، ایجاد کنم. داشتن توانایی بسته بندی استقرارهای من مانند این ، داشتن چندین محیط یک تکه کیک را ایجاد می کند.
ارزش ها
اگر الگوها طرح منابع ما هستند ، مقادیر آن طرح ها را با پیاده سازی های بتونی پر می کنند. مقادیر همچنین منابع YAML هستند که دارای سلسله مراتب کاربرد هستند. هر پروژه باید یک پیش فرض داشته باشد values.yaml پرونده این پرونده مقادیر می تواند توسط یک پرونده مقادیر عرضه شده نادیده گرفته شود و سپس آن پرونده را می توان با خط فرمان نادیده گرفت set استدلال ها متداول ترین روش ایجاد یک فایل مقادیر در هر محیط یا هر نسخه است که به دنبال آن هستید.
در این مثال ، من یک فایل Override را نشان نمی دهم ، اما اگر می خواهید با کد بازی کنید ، فقط کپی کنید values.yaml و پرونده جدید را نامگذاری کنید second-values.yaml و وقتی می خواهید نمودار را اجرا کنید ، helm install your-release ./chart -f second-values.yaml و خواهید دید که چگونه می توانید 2 استقرار داشته باشید که توسط نسخه های مختلف با ارزش های مختلف اداره می شوند.
پرونده مقادیر می تواند ساختاری را که انتخاب می کنید داشته باشد. کمی به آن فکر کنید مانند API که به سازندگان الگو می دهید تا هنگام تنظیم منابع ، آنچه را که لازم دارند را پر کنند. این پرونده می تواند توخالی یا مسطح یا کمی از هر دو باشد. من تمایل دارم که از یک رویکرد تو در تو حمایت کنم ، اما فقط 3 سطح عمق دارد. این واقعاً فقط اولویت من است ، بنابراین در اینجا احساس راحتی کنید.
در من values.yaml پرونده ، زمینه هایی را که در الگوهای خود استفاده کرده ام برای پر کردن آنچه مهم است ، متوجه خواهید شد.
replicas: 2
container:
containerPorts:
port: 80
protocol: TCP
targetPort: 3000
image:
path: public.ecr.aws/f8u4w2p3/rust/rust-service-1:latest
environmentVariables:
bindAddress: 0.0.0.0:3000
rustLog: "INFO"
باز هم ، مثال ساده ، اما می توانید این کار را خیلی بیشتر کنید تا تعاریف منابع بسیار گسترده ای را تهیه کنید.
نصب نمودار
نمودارهای کلاه ایمنی هم هستند installedبا upgraded، یا deletedبشر CLI بسیار قدرتمند است ، اما این 3 دستور است که من می خواهم در اینجا کشف کنم.
نصب کردن
نصب نمودار من این شکل را از ترمینال می گیرد.
helm install first-release ./chart
در first-release راهی است که Helm با انتشار منابع منابع را مدیریت می کند. باز هم ، من می توانستم نسخه های زیادی داشته باشم یا فقط می توانم از آن استفاده کنم. انعطاف پذیری در اینجا قدرت زیادی را فراهم می کند. وقتی این دستور را اجرا می کنم ، هر 3 الگوهای من که منابع را تعریف می کنند ایجاد می شوند.
نقشه پیکربندی
اعزام
غلاف
بالا بردن
من اکنون با منابع مستقر یک نمودار دارم ، اما چگونه می توانم آن را اصلاح کنم؟ اگر برخی از مقادیر خود را تغییر دادم values.yaml پرونده ، من می توانم نسخه را با استفاده از به روزرسانی اصلاح کنم.
helm upgrade first-release ./chart
حذف کردن
و وقتی تمام شد ، فقط حذف کنید.
helm delete first-release
پیچیدن
احساس می کنم سطح کلاه ایمنی را در اینجا به سختی خراشیده ام ، اما امیدوارم فقط کافی باشد که قدرت و سفارشی سازی را که می توان هنگام استفاده از HELM برای منابع Kubernetes خود نشان داد ، به شما نشان داد. من از Kustomize محبوب در پروژه های دیگر استفاده کرده ام و در حالی که من آن رویکرد را دوست دارم ، هلم احساس می کند که کنترل بیشتری دارم و کد کمتری می نویسم. من منابع خود را یک بار کنار هم قرار داده ام و سپس اجازه می دهم که Helm ارزش های خود را پر کند.
اگر علاقه مند به امتحان کردن مثال فوق هستید ، در اینجا مخزن GitHub است که یک راه حل کامل کار دارد. آن را کلون کرده و آن را با نیاز خود تنظیم کنید تا ببینید چگونه HELM کار می کند. نمودار مبارک!
با تشکر از خواندن و ساختمان شاد!
