🥇 সংস্করণযুক্ত ডকুমেন্টেশন সাইটের উদাহরণ ব্যবহার করে werf সহ ডকার চিত্রগুলির গতিশীল সমাবেশ এবং স্থাপনা

আমরা ইতিমধ্যে আমাদের GitOps টুল সম্পর্কে একাধিকবার কথা বলেছি। werf, এবং এই সময় আমরা প্রকল্পের ডকুমেন্টেশনের সাথে সাইটটি একত্রিত করার আমাদের অভিজ্ঞতা শেয়ার করতে চাই - werf.io (এর রাশিয়ান সংস্করণ en.werf.io) এটি একটি সাধারণ স্ট্যাটিক সাইট, তবে এর সমাবেশটি আকর্ষণীয় যে এটি একটি গতিশীল সংখ্যক নিদর্শন ব্যবহার করে নির্মিত হয়েছে।

সাইটের কাঠামোর সূক্ষ্মতাগুলিতে যান: সমস্ত সংস্করণের জন্য একটি সাধারণ মেনু তৈরি করা, রিলিজ সম্পর্কে তথ্য সহ পৃষ্ঠাগুলি ইত্যাদি। - আমরা করবো না। পরিবর্তে, আসুন ডায়নামিক সমাবেশের সমস্যা এবং বৈশিষ্ট্য এবং সহগামী CI/CD প্রক্রিয়াগুলির উপর একটু ফোকাস করি।

ভূমিকা: সাইট কিভাবে কাজ করে

শুরুতে, werf ডকুমেন্টেশন এর কোড সহ সংরক্ষণ করা হয়। এটি কিছু উন্নয়ন প্রয়োজনীয়তা আরোপ করে যা সাধারণত এই নিবন্ধের সুযোগের বাইরে, তবে সর্বনিম্নভাবে এটি বলা যেতে পারে যে:

ডকুমেন্টেশন আপডেট না করে নতুন ওয়ার্ফ ফাংশন প্রকাশ করা উচিত নয় এবং বিপরীতভাবে, ডকুমেন্টেশনে যে কোনো পরিবর্তন ওয়ারফের একটি নতুন সংস্করণ প্রকাশকে বোঝায়;
প্রকল্পের একটি মোটামুটি নিবিড় উন্নয়ন আছে: নতুন সংস্করণগুলি দিনে বেশ কয়েকবার প্রকাশ করা যেতে পারে;
ডকুমেন্টেশনের একটি নতুন সংস্করণ সহ একটি সাইট স্থাপন করার জন্য যে কোনো ম্যানুয়াল অপারেশন অন্তত ক্লান্তিকর;
প্রকল্পটি একটি শব্দার্থিক পদ্ধতি গ্রহণ করে সংস্করণ, 5টি স্থিতিশীলতা চ্যানেল সহ। রিলিজ প্রক্রিয়ায় স্থিতিশীলতা বৃদ্ধির জন্য চ্যানেলের মাধ্যমে সংস্করণের অনুক্রমিক উত্তরণ জড়িত: আলফা থেকে রক-সলিড পর্যন্ত;
সাইটের একটি রাশিয়ান-ভাষা সংস্করণ রয়েছে, যা প্রধান (অর্থাৎ, ইংরেজি-ভাষা) সংস্করণের সমান্তরালে "বাঁচে এবং বিকাশ করে" (অর্থাৎ, যার বিষয়বস্তু আপডেট করা হয়)।

ব্যবহারকারীর কাছ থেকে এই সমস্ত "অভ্যন্তরীণ রান্নাঘর" লুকানোর জন্য, তাকে এমন কিছু অফার করে যা "শুধু কাজ করে", আমরা তা করেছি পৃথক ওয়ার্ফ ইনস্টলেশন এবং আপডেট টুল - এটা মাল্টিওয়ার্ফ. আপনাকে শুধুমাত্র রিলিজ নম্বর এবং স্থিতিশীলতা চ্যানেলটি নির্দিষ্ট করতে হবে যা আপনি ব্যবহার করার জন্য প্রস্তুত, এবং মাল্টিওয়ার্ফ চ্যানেলে একটি নতুন সংস্করণ আছে কিনা তা পরীক্ষা করবে এবং প্রয়োজনে এটি ডাউনলোড করবে।

ওয়েবসাইটে সংস্করণ নির্বাচন মেনুতে, werf-এর সর্বশেষ সংস্করণগুলি প্রতিটি চ্যানেলে উপলব্ধ। ডিফল্টরূপে, ঠিকানা দ্বারা werf.io/documentation সর্বশেষ প্রকাশের জন্য সবচেয়ে স্থিতিশীল চ্যানেলের সংস্করণটি খোলে - এটি সার্চ ইঞ্জিন দ্বারাও সূচিত করা হয়। চ্যানেলের জন্য ডকুমেন্টেশন আলাদা ঠিকানায় পাওয়া যায় (উদাহরণস্বরূপ, werf.io/v1.0-beta/documentation বিটা রিলিজের জন্য 1.0)।

মোট, সাইটে নিম্নলিখিত সংস্করণ উপলব্ধ আছে:

রুট (ডিফল্টরূপে খোলে),
প্রতিটি রিলিজের প্রতিটি সক্রিয় আপডেট চ্যানেলের জন্য (উদাহরণস্বরূপ, werf.io/v1.0-বিটা).

একটি সাইটের একটি নির্দিষ্ট সংস্করণ তৈরি করতে, সাধারণভাবে, এটি ব্যবহার করে কম্পাইল করা যথেষ্ট Jekyllডিরেক্টরিতে চালানোর মাধ্যমে /docs werf সংগ্রহস্থল সংশ্লিষ্ট কমান্ড (jekyll build), প্রয়োজনীয় সংস্করণের গিট ট্যাগে স্যুইচ করার পরে।

এটি শুধুমাত্র যোগ করার জন্য অবশেষ:

ইউটিলিটি নিজেই (ওয়ার্ফ) সমাবেশের জন্য ব্যবহৃত হয়;
সিআই/সিডি প্রক্রিয়াগুলি গিটল্যাব সিআই-এর ভিত্তিতে তৈরি করা হয়;
এবং এই সব, অবশ্যই, Kubernetes চলে.

কর্ম

এখন আসুন এমন কাজগুলি প্রণয়ন করি যা সমস্ত বর্ণিত সুনির্দিষ্ট বিষয়গুলিকে বিবেচনা করে:

যেকোনো আপডেট চ্যানেলে werf সংস্করণ পরিবর্তন করার পর সাইটে ডকুমেন্টেশন স্বয়ংক্রিয়ভাবে আপডেট করা উচিত.
উন্নয়নের জন্য আপনাকে মাঝে মাঝে সক্ষম হতে হবে সাইটের পূর্বরূপ সংস্করণ দেখুন.

সংশ্লিষ্ট গিট ট্যাগগুলি থেকে যে কোনও চ্যানেলে সংস্করণ পরিবর্তন করার পরে সাইটটি অবশ্যই পুনরায় কম্পাইল করা উচিত, তবে চিত্রটি তৈরি করার প্রক্রিয়াতে আমরা নিম্নলিখিত বৈশিষ্ট্যগুলি পাব:

যেহেতু চ্যানেলগুলির সংস্করণগুলির তালিকা পরিবর্তিত হয়, শুধুমাত্র সেই চ্যানেলগুলির জন্য ডকুমেন্টেশন পুনর্নির্মাণ করা প্রয়োজন যেখানে সংস্করণটি পরিবর্তিত হয়েছে৷ সব পরে, আবার সবকিছু পুনর্নির্মাণ খুব সুন্দর নয়।
রিলিজের জন্য চ্যানেলের সেট পরিবর্তিত হতে পারে। কিছু সময়ে, উদাহরণস্বরূপ, চ্যানেলগুলিতে প্রারম্ভিক-অ্যাক্সেস 1.1 রিলিজের চেয়ে বেশি স্থিতিশীল সংস্করণ নাও থাকতে পারে, তবে সময়ের সাথে সাথে সেগুলি উপস্থিত হবে - এই ক্ষেত্রে, আপনার কি ম্যানুয়ালি সমাবেশ পরিবর্তন করা উচিত নয়?

এটা যে সক্রিয় আউট সমাবেশ বহিরাগত ডেটা পরিবর্তনের উপর নির্ভর করে.

বাস্তবায়ন

একটি পদ্ধতি নির্বাচন

বিকল্পভাবে, আপনি Kubernetes-এ একটি পৃথক পড হিসাবে প্রতিটি প্রয়োজনীয় সংস্করণ চালাতে পারেন। এই বিকল্পটি ক্লাস্টারে একটি বৃহত্তর সংখ্যক বস্তুকে বোঝায়, যা স্থিতিশীল ওয়ার্ফ রিলিজের সংখ্যা বৃদ্ধির সাথে বৃদ্ধি পাবে। এবং এটি, ঘুরে, আরও জটিল রক্ষণাবেক্ষণ বোঝায়: প্রতিটি সংস্করণের নিজস্ব HTTP সার্ভার রয়েছে এবং একটি ছোট লোড সহ। অবশ্যই, এটি বৃহত্তর সম্পদ খরচ entails.

আমরা একই পথ ধরলাম একটি ছবিতে প্রয়োজনীয় সমস্ত সংস্করণ একত্রিত করা. সাইটের সমস্ত সংস্করণের সংকলিত পরিসংখ্যান এনজিআইএনএক্স সহ একটি পাত্রে অবস্থিত এবং সংশ্লিষ্ট স্থাপনায় ট্রাফিক এনজিআইএনএক্স প্রবেশের মাধ্যমে আসে। একটি সাধারণ কাঠামো - একটি স্টেটলেস অ্যাপ্লিকেশন - আপনাকে কুবারনেটস নিজেই ব্যবহার করে সহজেই স্থাপনা (লোডের উপর নির্ভর করে) স্কেল করতে দেয়।

আরও সুনির্দিষ্ট হতে, আমরা দুটি চিত্র সংগ্রহ করছি: একটি উত্পাদন সার্কিটের জন্য, দ্বিতীয়টি দেব সার্কিটের জন্য একটি অতিরিক্ত। অতিরিক্ত চিত্রটি শুধুমাত্র প্রধানটির সাথে একত্রে ডেভ সার্কিটে ব্যবহার করা হয় (লঞ্চ করা হয়) এবং এতে পর্যালোচনা প্রতিশ্রুতি থেকে সাইটের সংস্করণ রয়েছে এবং ইনগ্রেস সংস্থান ব্যবহার করে তাদের মধ্যে রাউটিং করা হয়।

ওয়ার্ফ বনাম গিট ক্লোন এবং আর্টিফ্যাক্টস

ইতিমধ্যে উল্লিখিত হিসাবে, ডকুমেন্টেশনের একটি নির্দিষ্ট সংস্করণের জন্য সাইট স্ট্যাটিক্স তৈরি করার জন্য, আপনাকে উপযুক্ত সংগ্রহস্থল ট্যাগে স্যুইচ করে তৈরি করতে হবে। আপনি একটি তালিকা থেকে উপযুক্ত ট্যাগ নির্বাচন করে প্রতিবার তৈরি করার সময় সংগ্রহস্থল ক্লোন করেও এটি করতে পারেন। যাইহোক, এটি একটি বরং সম্পদ-নিবিড় অপারেশন এবং তদ্ব্যতীত, অ-তুচ্ছ নির্দেশাবলী লেখার প্রয়োজন... আরেকটি গুরুতর অসুবিধা হল যে এই পদ্ধতির সাহায্যে সমাবেশের সময় কিছু ক্যাশে করার কোন উপায় নেই।

এখানে werf ইউটিলিটি নিজেই আমাদের সাহায্যে আসে, বাস্তবায়ন করে স্মার্ট ক্যাশিং এবং আপনাকে ব্যবহার করার অনুমতি দেয় বাহ্যিক সংগ্রহস্থল. সংগ্রহস্থল থেকে কোড যোগ করার জন্য werf ব্যবহার করা উল্লেখযোগ্যভাবে বিল্ডের গতি বাড়াবে, কারণ werf মূলত একবার সংগ্রহস্থল ক্লোন করে এবং তারপর কার্যকর করে শুধুমাত্র fetch যদি প্রয়োজন হয় তাহলে। উপরন্তু, সংগ্রহস্থল থেকে তথ্য যোগ করার সময়, আমরা শুধুমাত্র প্রয়োজনীয় ডিরেক্টরি নির্বাচন করতে পারি (আমাদের ক্ষেত্রে এটি ডিরেক্টরি docs), যা যোগ করা ডেটার পরিমাণ উল্লেখযোগ্যভাবে হ্রাস করবে।

যেহেতু জেকিল একটি টুল যা স্ট্যাটিক ডেটা কম্পাইল করার জন্য ডিজাইন করা হয়েছে এবং চূড়ান্ত ছবিতে এর প্রয়োজন নেই, তাই কম্পাইল করা যৌক্তিক হবে werf artifact, এবং চূড়ান্ত চিত্রে শুধুমাত্র সংকলনের ফলাফল আমদানি করুন.

আমরা werf.yaml লিখি

সুতরাং, আমরা সিদ্ধান্ত নিয়েছি যে আমরা প্রতিটি সংস্করণকে একটি পৃথক ওয়ার্ফ আর্টিফ্যাক্টে কম্পাইল করব। যাইহোক আমরা সমাবেশের সময় এই নিদর্শনগুলির কতগুলি থাকবে তা আমরা জানি না, তাই আমরা একটি নির্দিষ্ট বিল্ড কনফিগারেশন লিখতে পারি না (কঠোরভাবে বলতে গেলে, আমরা এখনও পারি, তবে এটি সম্পূর্ণ কার্যকর হবে না)।

werf আপনাকে ব্যবহার করতে দেয় টেমপ্লেট যান আপনার কনফিগারেশন ফাইলে (werf.yaml), এবং এটি এটি সম্ভব করে তোলে ফ্লাইতে কনফিগারেশন তৈরি করুন বাহ্যিক ডেটার উপর নির্ভর করে (আপনার যা প্রয়োজন!) আমাদের ক্ষেত্রে বাহ্যিক ডেটা হল সংস্করণ এবং রিলিজ সম্পর্কে তথ্য, যার ভিত্তিতে আমরা প্রয়োজনীয় সংখ্যক নিদর্শন সংগ্রহ করি এবং ফলস্বরূপ আমরা দুটি চিত্র পাই: werf-doc и werf-dev বিভিন্ন সার্কিটে চালানোর জন্য।

বাহ্যিক তথ্য পরিবেশ ভেরিয়েবল মাধ্যমে পাস করা হয়. এখানে তাদের রচনা:

RELEASES — রিলিজগুলির একটি তালিকা এবং werf এর সংশ্লিষ্ট বর্তমান সংস্করণ সহ একটি লাইন, বিন্যাসে মানগুলির একটি স্থান-বিচ্ছিন্ন তালিকা আকারে <НОМЕР_РЕЛИЗА>%<НОМЕР_ВЕРСИИ>। উদাহরণ: 1.0%v1.0.4-beta.20
CHANNELS — চ্যানেলগুলির একটি তালিকা এবং werf এর সংশ্লিষ্ট বর্তমান সংস্করণ সহ একটি লাইন, বিন্যাসে মানগুলির একটি স্থান-বিচ্ছিন্ন তালিকা আকারে <КАНАЛ>%<НОМЕР_ВЕРСИИ>। উদাহরণ: 1.0-beta%v1.0.4-beta.20 1.0-alpha%v1.0.5-alpha.22
ROOT_VERSION — werf রিলিজ সংস্করণ সাইটে ডিফল্টরূপে প্রদর্শিত হবে (সর্বোচ্চ রিলিজ সংখ্যা দ্বারা ডকুমেন্টেশন প্রদর্শন করা সর্বদা প্রয়োজন হয় না)। উদাহরণ: v1.0.4-beta.20
REVIEW_SHA — রিভিউ কমিটের হ্যাশ যা থেকে আপনাকে টেস্ট লুপের সংস্করণ তৈরি করতে হবে।

এই ভেরিয়েবলগুলি GitLab CI পাইপলাইনে পূরণ করা হবে এবং ঠিক কিভাবে নিচে লেখা আছে।

প্রথমত, সুবিধার জন্য, আমরা সংজ্ঞায়িত করি werf.yaml টেমপ্লেট ভেরিয়েবলগুলিতে যান, পরিবেশের ভেরিয়েবল থেকে তাদের মান নির্ধারণ করুন:

{{ $_ := set . "WerfVersions" (cat (env "CHANNELS") (env "RELEASES") | splitList " ") }}
{{ $Root := . }}
{{ $_ := set . "WerfRootVersion" (env "ROOT_VERSION") }}
{{ $_ := set . "WerfReviewCommit" (env "REVIEW_SHA") }}

সাইটের স্ট্যাটিক সংস্করণ কম্পাইল করার জন্য আর্টিফ্যাক্টের বিবরণ সাধারণত আমাদের প্রয়োজনীয় সমস্ত ক্ষেত্রে একই হয় (রুট সংস্করণ তৈরি করা, সেইসাথে ডেভ সার্কিটের সংস্করণ সহ)। অতএব, আমরা ফাংশন ব্যবহার করে এটি একটি পৃথক ব্লকে স্থানান্তর করব define - পরবর্তীতে পুনরায় ব্যবহারের জন্য include. আমরা টেমপ্লেটে নিম্নলিখিত আর্গুমেন্ট পাস করব:

Version — তৈরি সংস্করণ (ট্যাগ নাম);
Channel — আপডেট চ্যানেলের নাম যার জন্য আর্টিফ্যাক্ট তৈরি করা হয়েছে;
Commit — কমিট হ্যাশ, যদি আর্টিফ্যাক্টটি রিভিউ কমিটের জন্য তৈরি করা হয়;
প্রসঙ্গ

আর্টিফ্যাক্ট টেমপ্লেট বর্ণনা

{{- define "doc_artifact" -}}
{{- $Root := index . "Root" -}}
artifact: doc-{{ .Channel }}
from: jekyll/builder:3
mount:
- from: build_dir
  to: /usr/local/bundle
ansible:
  install:
  - shell: |
      export PATH=/usr/jekyll/bin/:$PATH
  - name: "Install Dependencies"
    shell: bundle install
    args:
      executable: /bin/bash
      chdir: /app/docs
  beforeSetup:
{{- if .Commit }}
  - shell: echo "Review SHA - {{ .Commit }}."
{{- end }}
{{- if eq .Channel "root" }}
  - name: "releases.yml HASH: {{ $Root.Files.Get "releases.yml" | sha256sum }}"
    copy:
      content: |
{{ $Root.Files.Get "releases.yml" | indent 8 }}
      dest:  /app/docs/_data/releases.yml
{{- else }}
  - file:
      path: /app/docs/_data/releases.yml
      state: touch
{{- end }}
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/
    - /app/ru_site/
  - file:
      dest: /app/docs/pages_ru/cli
      state: link
      src: /app/docs/pages/cli
  - shell: |
      echo -e "werfVersion: {{ .Version }}nwerfChannel: {{ .Channel }}" > /tmp/_config_additional.yml
      export PATH=/usr/jekyll/bin/:$PATH
{{- if and (ne .Version "review") (ne .Channel "root") }}
{{- $_ := set . "BaseURL" ( printf "v%s" .Channel ) }}
{{- else if ne .Channel "root" }}
{{- $_ := set . "BaseURL" .Channel }}
{{- end }}
      jekyll build -s /app/docs  -d /app/_main_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/tmp/_config_additional.yml
      jekyll build -s /app/docs  -d /app/_ru_site/{{ if .BaseURL }} --baseurl /{{ .BaseURL }}{{ end }} --config /app/docs/_config.yml,/app/docs/_config_ru.yml,/tmp/_config_additional.yml
    args:
      executable: /bin/bash
      chdir: /app/docs
git:
- url: https://github.com/flant/werf.git
  to: /app/
  owner: jekyll
  group: jekyll
{{- if .Commit }}
  commit: {{ .Commit }}
{{- else }}
  tag: {{ .Version }}
{{- end }}
  stageDependencies:
    install: ['docs/Gemfile','docs/Gemfile.lock']
    beforeSetup: '**/*'
  includePaths: 'docs'
  excludePaths: '**/*.sh'
{{- end }}

শিল্পকর্মের নাম অবশ্যই অনন্য হতে হবে। আমরা এটি অর্জন করতে পারি, উদাহরণস্বরূপ, চ্যানেলের নাম যোগ করে (ভেরিয়েবলের মান .Channel) শিল্পকর্মের নামের প্রত্যয় হিসাবে: artifact: doc-{{ .Channel }}. কিন্তু আপনাকে বুঝতে হবে যে আর্টিফ্যাক্ট থেকে আমদানি করার সময়, আপনাকে একই নাম উল্লেখ করতে হবে।

একটি আর্টিফ্যাক্ট বর্ণনা করার সময়, নিম্নলিখিত ওয়ার্ফ বৈশিষ্ট্যটি ব্যবহার করা হয়: মাউন্ট. মাউন্টিং পরিষেবা ডিরেক্টরি নির্দেশ করে build_dir আপনাকে পাইপলাইন রানের মধ্যে জেকিল ক্যাশে সংরক্ষণ করতে দেয়, যা উল্লেখযোগ্যভাবে reassembly আপ গতি.

আপনি ফাইলের ব্যবহারও লক্ষ্য করেছেন releases.yml থেকে অনুরোধ করা রিলিজ ডেটা সহ একটি YAML ফাইল github.com (একটি পাইপলাইন চালানোর সময় প্রাপ্ত একটি শিল্পকর্ম)। সাইটটি কম্পাইল করার সময় এটি প্রয়োজন হয়, তবে নিবন্ধের প্রসঙ্গে এটি আমাদের কাছে আকর্ষণীয় কারণ এটি তার অবস্থার উপর নির্ভর করে শুধুমাত্র একটি আর্টিফ্যাক্টের পুনরায় একত্রিত করা — সাইটের রুট সংস্করণের একটি আর্টিফ্যাক্ট (অন্যান্য শিল্পকর্মে এটির প্রয়োজন নেই)।

এটি শর্তসাপেক্ষ বিবৃতি ব্যবহার করে প্রয়োগ করা হয় if টেমপ্লেট এবং ডিজাইন যান {{ $Root.Files.Get "releases.yml" | sha256sum }} পর্যায়ে পর্যায়গুলি. এটি নিম্নরূপ কাজ করে: রুট সংস্করণের জন্য একটি আর্টিফ্যাক্ট তৈরি করার সময় (ভেরিয়েবল .Channel হয় root) ফাইল হ্যাশ releases.yml পুরো পর্যায়ের স্বাক্ষরকে প্রভাবিত করে, যেহেতু এটি উত্তরযোগ্য টাস্কের নামের অংশ (প্যারামিটার name) এইভাবে, যখন পরিবর্তন বিষয়বস্তু ফাইল releases.yml সংশ্লিষ্ট শিল্পকর্ম পুনরায় একত্রিত করা হবে।

অনুগ্রহ করে একটি বহিরাগত সংগ্রহস্থলের সাথে কাজ করার দিকেও মনোযোগ দিন। থেকে একটি শিল্পকর্মের ছবিতে werf সংগ্রহস্থল, শুধুমাত্র ডিরেক্টরি যোগ করা হয় /docs, এবং পাস করা পরামিতিগুলির উপর নির্ভর করে, প্রয়োজনীয় ট্যাগ বা পর্যালোচনা প্রতিশ্রুতির ডেটা অবিলম্বে যোগ করা হয়।

চ্যানেল এবং রিলিজের স্থানান্তরিত সংস্করণগুলির আর্টিফ্যাক্টের একটি বিবরণ তৈরি করতে আর্টিফ্যাক্ট টেমপ্লেট ব্যবহার করতে, আমরা ভেরিয়েবলের উপর একটি লুপ সংগঠিত করি .WerfVersions в werf.yaml:

{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ dict "Version" $VersionsDict._1 "Channel" $VersionsDict._0 "Root" $Root | include "doc_artifact" }}
---
{{ end -}}

কারণ লুপটি বেশ কয়েকটি নিদর্শন তৈরি করবে (আমরা আশা করি), তাদের মধ্যে বিভাজকটি বিবেচনা করা প্রয়োজন - ক্রমটি --- (কনফিগারেশন ফাইল সিনট্যাক্স সম্পর্কে আরও তথ্যের জন্য, দেখুন ডকুমেন্টেশন) পূর্বে সংজ্ঞায়িত করা হয়েছে, লুপে একটি টেমপ্লেট কল করার সময়, আমরা সংস্করণ প্যারামিটার, URL এবং রুট প্রসঙ্গ পাস করি।

একইভাবে, কিন্তু লুপ ছাড়াই, আমরা আর্টিফ্যাক্ট টেমপ্লেটকে "বিশেষ ক্ষেত্রে" বলি: রুট সংস্করণের জন্য, সেইসাথে পর্যালোচনা প্রতিশ্রুতির সংস্করণের জন্য:

{{ dict "Version" .WerfRootVersion "Channel" "root" "Root" $Root  | include "doc_artifact" }}
---
{{- if .WerfReviewCommit }}
{{ dict "Version" "review" "Channel" "review" "Commit" .WerfReviewCommit "Root" $Root  | include "doc_artifact" }}
{{- end }}

অনুগ্রহ করে মনে রাখবেন যে রিভিউ কমিটের আর্টিফ্যাক্ট শুধুমাত্র তখনই তৈরি করা হবে যদি পরিবর্তনশীল সেট করা থাকে .WerfReviewCommit.

শিল্পকর্ম প্রস্তুত - এটি আমদানি শুরু করার সময়!

কুবারনেটে চালানোর জন্য ডিজাইন করা চূড়ান্ত চিত্রটি একটি সার্ভার কনফিগারেশন ফাইল যুক্ত একটি নিয়মিত NGINX nginx.conf এবং নিদর্শন থেকে স্ট্যাটিক. সাইটের রুট সংস্করণের আর্টিফ্যাক্ট ছাড়াও, আমাদের ভেরিয়েবলের লুপটি পুনরাবৃত্তি করতে হবে .WerfVersions চ্যানেলের আর্টিফ্যাক্ট আমদানি করতে এবং সংস্করণ প্রকাশ করতে + আর্টিফ্যাক্ট নামকরণের নিয়ম অনুসরণ করুন যা আমরা আগে গ্রহণ করেছি। যেহেতু প্রতিটি আর্টিফ্যাক্ট দুটি ভাষার জন্য সাইটের সংস্করণ সংরক্ষণ করে, আমরা সেগুলিকে কনফিগারেশন দ্বারা প্রদত্ত জায়গায় আমদানি করি।

চূড়ান্ত চিত্রের বর্ণনা werf-doc

image: werf-doc
from: nginx:stable-alpine
ansible:
  setup:
  - name: "Setup /etc/nginx/nginx.conf"
    copy:
      content: |
{{ .Files.Get ".werf/nginx.conf" | indent 8 }}
      dest: /etc/nginx/nginx.conf
  - file:
      path: "{{`{{ item }}`}}"
      state: directory
      mode: 0777
    with_items:
    - /app/main_site/assets
    - /app/ru_site/assets
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_main_site
  to: /app/main_site/v{{ $Channel }}
  before: setup
{{ end -}}
{{ range .WerfVersions -}}
{{ $VersionsDict := splitn "%" 2 . -}}
{{ $Channel := $VersionsDict._0 -}}
{{ $Version := $VersionsDict._1 -}}
- artifact: doc-{{ $Channel }}
  add: /app/_ru_site
  to: /app/ru_site/v{{ $Channel }}
  before: setup
{{ end -}}

অতিরিক্ত চিত্র, যা প্রধানটির সাথে একসাথে, ডেভ সার্কিটে লঞ্চ করা হয়েছে, এতে সাইটের মাত্র দুটি সংস্করণ রয়েছে: পর্যালোচনা প্রতিশ্রুতি থেকে সংস্করণ এবং সাইটের মূল সংস্করণ (সাধারণ সম্পদ রয়েছে এবং, যদি আপনি মনে রাখেন , তথ্য প্রকাশ করুন)। সুতরাং, অতিরিক্ত চিত্রটি শুধুমাত্র আমদানি বিভাগে (এবং, অবশ্যই, নামে) প্রধান থেকে পৃথক হবে:

image: werf-dev
...
import:
- artifact: doc-root
  add: /app/_main_site
  to: /app/main_site
  before: setup
- artifact: doc-root
  add: /app/_ru_site
  to: /app/ru_site
  before: setup
{{- if .WerfReviewCommit  }}
- artifact: doc-review
  add: /app/_main_site
  to: /app/main_site/review
  before: setup
- artifact: doc-review
  add: /app/_ru_site
  to: /app/ru_site/review
  before: setup
{{- end }}

উপরে উল্লিখিত হিসাবে, পর্যালোচনা প্রতিশ্রুতির জন্য আর্টিফ্যাক্ট শুধুমাত্র তখনই তৈরি হবে যখন সেট এনভায়রনমেন্ট ভেরিয়েবল চালানো হবে REVIEW_SHA. পরিবেশ পরিবর্তনশীল না থাকলে werf-dev ইমেজ তৈরি না করা সম্ভব হবে REVIEW_SHA, কিন্তু করার জন্য নীতি দ্বারা পরিষ্কার werf-এ ডকার ইমেজগুলি werf-dev ইমেজের জন্য কাজ করেছে, আমরা পাইপলাইন কাঠামোকে সহজ করার জন্য এটিকে শুধুমাত্র রুট সংস্করণের আর্টিফ্যাক্ট (এটি ইতিমধ্যেই তৈরি করা হয়েছে) দিয়ে তৈরি করা ছেড়ে দেব।

সমাবেশ প্রস্তুত! আসুন সিআই/সিডি এবং গুরুত্বপূর্ণ সূক্ষ্ম বিষয়গুলিতে এগিয়ে যাই।

GitLab CI-এ পাইপলাইন এবং গতিশীল বিল্ডের বৈশিষ্ট্য

বিল্ড চালানোর সময় আমাদের ব্যবহৃত পরিবেশ ভেরিয়েবল সেট করতে হবে werf.yaml. এটি REVIEW_SHA ভেরিয়েবলের ক্ষেত্রে প্রযোজ্য নয়, যা আমরা GitHub হুক থেকে পাইপলাইন কল করার সময় সেট করব।

আমরা একটি ব্যাশ স্ক্রিপ্টে প্রয়োজনীয় বাহ্যিক ডেটা তৈরি করব generate_artifacts, যা দুটি গিটল্যাব পাইপলাইন শিল্পকর্ম তৈরি করবে:

файл releases.yml রিলিজ ডেটা সহ,
файл common_envs.sh, রপ্তানি করা পরিবেশ ভেরিয়েবল ধারণকারী.

ফাইল বিষয়বস্তু generate_artifacts আপনি আমাদের মধ্যে পাবেন উদাহরণ সহ সংগ্রহস্থল. তথ্য প্রাপ্তি নিজেই নিবন্ধের বিষয় নয়, কিন্তু ফাইল common_envs.sh আমাদের জন্য গুরুত্বপূর্ণ, কারণ werf এর কাজ এর উপর নির্ভর করে। এর বিষয়বস্তুর একটি উদাহরণ:

export RELEASES='1.0%v1.0.6-4'
export CHANNELS='1.0-alpha%v1.0.7-1 1.0-beta%v1.0.7-1 1.0-ea%v1.0.6-4 1.0-stable%v1.0.6-4 1.0-rock-solid%v1.0.6-4'
export ROOT_VERSION='v1.0.6-4'

আপনি যেমন একটি স্ক্রিপ্টের আউটপুট ব্যবহার করতে পারেন, উদাহরণস্বরূপ, ব্যাশ ফাংশন ব্যবহার করে source.

এখন আসছে মজার ব্যাপারটি। অ্যাপ্লিকেশনটির নির্মাণ এবং স্থাপনা উভয়ই সঠিকভাবে কাজ করার জন্য, এটি নিশ্চিত করা প্রয়োজন werf.yaml মনে হচ্ছিল একই অন্তত একটি পাইপলাইনের মধ্যে. যদি এই শর্তটি পূরণ করা না হয়, তাহলে ওয়ারফ সমাবেশের সময় গণনা করে এবং উদাহরণস্বরূপ, স্থাপনার পর্যায়গুলির স্বাক্ষরগুলি ভিন্ন হবে৷ এটি একটি স্থাপনার ত্রুটির দিকে পরিচালিত করবে, কারণ... স্থাপনার জন্য প্রয়োজনীয় ছবি অনুপস্থিত হবে।

অন্য কথায়, যদি সাইটের চিত্রের সমাবেশের সময় রিলিজ এবং সংস্করণগুলির তথ্য একই হয় এবং স্থাপনার সময় একটি নতুন সংস্করণ প্রকাশিত হয় এবং পরিবেশের ভেরিয়েবলের বিভিন্ন মান থাকে, তাহলে স্থাপনাটি একটি ত্রুটির সাথে ব্যর্থ হবে: সর্বোপরি, নতুন সংস্করণের শিল্পকর্মটি এখনও নির্মিত হয়নি।

যদি প্রজন্ম werf.yaml বাহ্যিক ডেটার উপর নির্ভর করে (উদাহরণস্বরূপ, বর্তমান সংস্করণগুলির একটি তালিকা, যেমন আমাদের ক্ষেত্রে), তারপরে এই জাতীয় ডেটার রচনা এবং মানগুলি পাইপলাইনের মধ্যে রেকর্ড করা উচিত। এটি বিশেষ করে গুরুত্বপূর্ণ যদি বাহ্যিক পরামিতিগুলি প্রায়শই পরিবর্তিত হয়।

আমরা করব বাহ্যিক ডেটা গ্রহণ এবং রেকর্ড করুন গিটল্যাবে পাইপলাইনের প্রথম পর্যায়ে (পূর্বনির্মাণ) এবং সেগুলিকে আরও আকারে প্রেরণ করুন গিটল্যাব সিআই আর্টিফ্যাক্ট. এটি আপনাকে একই কনফিগারেশনের সাথে পাইপলাইন কাজগুলি (বিল্ড, স্থাপন, পরিষ্কার) চালানো এবং পুনরায় চালু করার অনুমতি দেবে werf.yaml.

মঞ্চের বিষয়বস্তু পূর্বনির্মাণ ফাইল .gitlab-ci.yml:

Prebuild:
  stage: prebuild
  script:
    - bash ./generate_artifacts 1> common_envs.sh
    - cat ./common_envs.sh
  artifacts:
    paths:
      - releases.yml
      - common_envs.sh
    expire_in: 2 week

আর্টিফ্যাক্টে বাহ্যিক ডেটা ক্যাপচার করার পরে, আপনি স্ট্যান্ডার্ড গিটল্যাব সিআই পাইপলাইন ধাপগুলি ব্যবহার করে তৈরি এবং স্থাপন করতে পারেন: তৈরি করুন এবং স্থাপন করুন। আমরা গিটহাব ওয়ার্ফ রিপোজিটরি থেকে হুক ব্যবহার করে পাইপলাইনটি নিজেই চালু করি (অর্থাৎ, যখন গিটহাবের সংগ্রহস্থলে পরিবর্তন হয়)। তাদের জন্য ডেটা বিভাগে গিটল্যাব প্রকল্প বৈশিষ্ট্যে পাওয়া যাবে CI/CD সেটিংস -> পাইপলাইন ট্রিগার, এবং তারপর গিটহাবে সংশ্লিষ্ট ওয়েবহুক তৈরি করুন (সেটিংস -> ওয়েবহুক).

বিল্ড স্টেজ এই মত দেখাবে:

Build:
  stage: build
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf build-and-publish --stages-storage :local
  except:
    refs:
      - schedules
  dependencies:
    - Prebuild

গিটল্যাব স্টেজ থেকে বিল্ড স্টেজে দুটি আর্টিফ্যাক্ট যুক্ত করবে পূর্বনির্মাণ, তাই আমরা গঠন ব্যবহার করে প্রস্তুত ইনপুট ডেটা সহ ভেরিয়েবল রপ্তানি করি source common_envs.sh. একটি সময়সূচী অনুযায়ী পাইপলাইন চালু করা ছাড়া আমরা সব ক্ষেত্রেই বিল্ড স্টেজ শুরু করি। সময়সূচী অনুসারে, আমরা পরিষ্কারের জন্য একটি পাইপলাইন চালাব - এই ক্ষেত্রে সমাবেশ করার প্রয়োজন নেই।

স্থাপনার পর্যায়ে, আমরা দুটি কাজ বর্ণনা করব - একটি YAML টেমপ্লেট ব্যবহার করে উৎপাদন এবং ডেভ সার্কিটে স্থাপনের জন্য আলাদাভাবে:

.base_deploy: &base_deploy
  stage: deploy
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - werf deploy --stages-storage :local
  dependencies:
    - Prebuild
  except:
    refs:
      - schedules

Deploy to Production:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: prod
  environment:
    name: production
    url: werf.io
  only:
    refs:
      - master
  except:
    variables:
      - $REVIEW_SHA
    refs:
      - schedules

Deploy to Test:
  <<: *base_deploy
  variables:
    WERF_KUBE_CONTEXT: dev
  environment:
    name: test
    url: werf.test.flant.com
  except:
    refs:
      - schedules
  only:
    variables:
      - $REVIEW_SHA

কার্যগুলি মূলত কেবলমাত্র ক্লাস্টার প্রেক্ষাপট নির্দেশ করার ক্ষেত্রে পৃথক হয় যার মধ্যে werf স্থাপন করা উচিত (WERF_KUBE_CONTEXT), এবং লুপ এনভায়রনমেন্ট ভেরিয়েবল সেট করা (environment.name и environment.url), যা পরে হেলম চার্ট টেমপ্লেটগুলিতে ব্যবহৃত হয়। আমরা টেমপ্লেটের বিষয়বস্তু প্রদান করব না, কারণ... প্রশ্নে থাকা বিষয়ের জন্য সেখানে আকর্ষণীয় কিছু নেই, তবে আপনি সেগুলি খুঁজে পেতে পারেন৷ নিবন্ধের জন্য সংগ্রহস্থল.

চূড়ান্ত স্পর্শ

যেহেতু ওয়ার্ফ সংস্করণগুলি প্রায়শই প্রকাশিত হয়, নতুন ছবিগুলি ঘন ঘন তৈরি করা হবে এবং ডকার রেজিস্ট্রি ক্রমাগত বৃদ্ধি পাবে। অতএব, নীতির উপর ভিত্তি করে স্বয়ংক্রিয় চিত্র পরিচ্ছন্নতা কনফিগার করা অপরিহার্য। এটা করা খুবই সহজ।

বাস্তবায়ন করতে আপনার প্রয়োজন হবে:

একটি পরিষ্কার পদক্ষেপ যোগ করুন .gitlab-ci.yml;
একটি পরিচ্ছন্নতার কাজের পর্যায়ক্রমিক সম্পাদন যোগ করুন;
একটি লেখার অ্যাক্সেস টোকেন সহ একটি পরিবেশ পরিবর্তনশীল সেট আপ করুন।

একটি পরিষ্কার পর্যায় যোগ করা হচ্ছে .gitlab-ci.yml:

Cleanup:
  stage: cleanup
  script:
    - type multiwerf && . $(multiwerf use 1.0 alpha --as-file)
    - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - source common_envs.sh
    - docker login -u nobody -p ${WERF_IMAGES_CLEANUP_PASSWORD} ${WERF_IMAGES_REPO}
    - werf cleanup --stages-storage :local
  only:
    refs:
      - schedules

আমরা ইতিমধ্যেই এর প্রায় সবগুলোই একটু বেশি দেখেছি - শুধুমাত্র এটি পরিষ্কার করার জন্য আপনাকে প্রথমে ডকার রেজিস্ট্রিতে ছবি মুছে ফেলার অধিকার আছে এমন একটি টোকেন দিয়ে ডকার রেজিস্ট্রিতে লগ ইন করতে হবে (স্বয়ংক্রিয়ভাবে জারি করা গিটল্যাব সিআই টাস্ক টোকেন এই ধরনের অধিকার আছে)। টোকেনটি অবশ্যই গিটল্যাবে আগে থেকেই তৈরি করতে হবে এবং এর মান অবশ্যই এনভায়রনমেন্ট ভেরিয়েবলে উল্লেখ করতে হবে WERF_IMAGES_CLEANUP_PASSWORD প্রকল্পের (CI/CD সেটিংস -> ভেরিয়েবল).

প্রয়োজনীয় সময়সূচীর সাথে একটি পরিষ্কারের কাজ যোগ করা হয় CI/CD ->
সূচী.

এটিই: ডকার রেজিস্ট্রির একটি প্রকল্প আর অব্যবহৃত চিত্রগুলি থেকে ক্রমাগত বৃদ্ধি পাবে না।

ব্যবহারিক অংশের শেষে, আমি আপনাকে মনে করিয়ে দিচ্ছি যে নিবন্ধ থেকে সম্পূর্ণ তালিকা পাওয়া যায় git:

gitlab-ci.yml;
werf.yaml.

ফল

আমরা একটি যৌক্তিক সমাবেশ কাঠামো পেয়েছি: প্রতি সংস্করণে একটি আর্টিফ্যাক্ট।
সমাবেশটি সর্বজনীন এবং যখন werf এর নতুন সংস্করণ প্রকাশ করা হয় তখন ম্যানুয়াল পরিবর্তনের প্রয়োজন হয় না: ওয়েবসাইটের ডকুমেন্টেশন স্বয়ংক্রিয়ভাবে আপডেট হয়।
দুটি ইমেজ বিভিন্ন কনট্যুর জন্য একত্রিত করা হয়.
এটা দ্রুত কাজ করে, কারণ ক্যাশিং যতটা সম্ভব ব্যবহার করা হয় - যখন werf-এর একটি নতুন সংস্করণ প্রকাশ করা হয় বা একটি GitHub হুক একটি পর্যালোচনা প্রতিশ্রুতির জন্য বলা হয়, শুধুমাত্র পরিবর্তিত সংস্করণের সাথে সংশ্লিষ্ট শিল্পকর্মটি পুনর্নির্মাণ করা হয়।
অব্যবহৃত চিত্রগুলি মুছে ফেলার বিষয়ে চিন্তা করার দরকার নেই: ওয়ার্ফ নীতি অনুসারে পরিষ্কার করা ডকার রেজিস্ট্রিকে ঠিক রাখবে।

তথ্যও

werf ব্যবহার করে অ্যাসেম্বলির ক্যাশিং এবং এক্সটার্নাল রিপোজিটরির সাথে কাজ করার সময় ক্যাশিং উভয়ের কারণে অ্যাসেম্বলিকে দ্রুত কাজ করতে দেয়।
বাহ্যিক গিট রিপোজিটরিগুলির সাথে কাজ করা প্রতিটি সময় সমগ্র সংগ্রহস্থল ক্লোন করার বা চতুর অপ্টিমাইজেশান লজিক দিয়ে চাকাটিকে পুনরায় উদ্ভাবনের প্রয়োজনীয়তা দূর করে। werf একটি ক্যাশে ব্যবহার করে এবং শুধুমাত্র একবার ক্লোনিং করে এবং তারপর ব্যবহার করে fetch এবং শুধুমাত্র যখন প্রয়োজন।
বিল্ড কনফিগারেশন ফাইলে Go টেমপ্লেট ব্যবহার করার ক্ষমতা werf.yaml আপনাকে একটি সমাবেশ বর্ণনা করতে দেয় যার ফলাফল বাহ্যিক ডেটার উপর নির্ভর করে।
মাউন্ট ইন ওয়ার্ফ ব্যবহার করে উল্লেখযোগ্যভাবে শিল্পকর্ম সংগ্রহের গতি বাড়ে - ক্যাশের কারণে, যা সমস্ত পাইপলাইনে সাধারণ।
werf ক্লিনআপ কনফিগার করা সহজ করে, যা গতিশীলভাবে নির্মাণ করার সময় বিশেষভাবে গুরুত্বপূর্ণ।

দ্রষ্টব্য

আমাদের ব্লগেও পড়ুন:

উত্স: www.habr.com