🥇 একটি "স্টার্টআপ" থেকে এক ডজন ডেটা সেন্টারে হাজার হাজার সার্ভারে। কিভাবে আমরা লিনাক্স পরিকাঠামোর বৃদ্ধির পেছনে ছুটলাম

যদি আপনার আইটি অবকাঠামো খুব দ্রুত বৃদ্ধি পায়, তাহলে শীঘ্রই বা পরে আপনি একটি পছন্দের মুখোমুখি হবেন: এটিকে সমর্থন করতে বা অটোমেশন শুরু করার জন্য রৈখিকভাবে মানবসম্পদ বাড়ান। কিছু বিন্দু পর্যন্ত, আমরা প্রথম দৃষ্টান্তে বাস করতাম, এবং তারপরে অবকাঠামো-এ-কোডের দীর্ঘ পথ শুরু হয়।

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

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

যাত্রা শুরু

আমাদের যাত্রার শুরুতে, আমাদের প্রযুক্তির স্ট্যাকটি দেখতে এইরকম ছিল:
OS CentOS 7
ফ্রিআইপিএ ডোমেন কন্ট্রোলার
অটোমেশন - উত্তরযোগ্য(+টাওয়ার), মুচি

এই সমস্ত 3টি ডোমেনে অবস্থিত ছিল, যা বিভিন্ন ডেটা সেন্টার জুড়ে বিস্তৃত ছিল। একটি ডেটা সেন্টারে অফিস সিস্টেম এবং পরীক্ষার সাইট রয়েছে, বাকিটিতে PROD রয়েছে।

এক পর্যায়ে সার্ভার তৈরি করা এইরকম দেখায়:

VM টেমপ্লেটে, CentOS ন্যূনতম এবং প্রয়োজনীয় ন্যূনতম সঠিক /etc/resolv.conf এর মত, বাকিটা আসে Ansible এর মাধ্যমে।

CMDB - এক্সেল।

যদি সার্ভারটি শারীরিক হয়, তাহলে ভার্চুয়াল মেশিনটি অনুলিপি করার পরিবর্তে, Cobbler ব্যবহার করে OS ইনস্টল করা হয়েছিল - লক্ষ্য সার্ভারের MAC ঠিকানাগুলি Cobbler কনফিগারে যোগ করা হয়, সার্ভারটি DHCP এর মাধ্যমে একটি IP ঠিকানা পায় এবং তারপরে OS যোগ করা হলো.

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

সেই সময়ে, আমাদের মধ্যে অনেকেই Ansible কে Bash-এর সুবিধাজনক এক্সটেনশন হিসেবে মনে করতাম এবং শেল এবং sed ব্যবহার করে ডিজাইনে বাদ দেইনি। সামগ্রিক Bashsible. এটি শেষ পর্যন্ত এই সত্যের দিকে পরিচালিত করে যে যদি কোনও কারণে প্লেবুকটি সার্ভারে কাজ না করে, তবে সার্ভারটি মুছে ফেলা, প্লেবুকটি ঠিক করা এবং আবার চালানো সহজ ছিল। মূলত স্ক্রিপ্টগুলির কোনও সংস্করণ ছিল না, কনফিগারেশনের কোনও বহনযোগ্যতা ছিল না।

উদাহরণস্বরূপ, আমরা সমস্ত সার্ভারে কিছু কনফিগার পরিবর্তন করতে চেয়েছিলাম:

আমরা লজিক্যাল সেগমেন্ট/ডেটা সেন্টারে বিদ্যমান সার্ভারে কনফিগারেশন পরিবর্তন করি। কখনও কখনও একদিনে নয় - অ্যাক্সেসযোগ্যতার প্রয়োজনীয়তা এবং বৃহৎ সংখ্যার আইন সমস্ত পরিবর্তন একবারে প্রয়োগ করার অনুমতি দেয় না। এবং কিছু পরিবর্তন সম্ভাব্য ধ্বংসাত্মক এবং কিছু পুনরায় চালু করার প্রয়োজন - পরিষেবাগুলি থেকে OS পর্যন্ত।
উত্তরে এটি ঠিক করা
আমরা মুচিতে এটি ঠিক করি
প্রতিটি লজিক্যাল সেগমেন্ট/ডেটা সেন্টারের জন্য N বার পুনরাবৃত্তি করুন

সমস্ত পরিবর্তনগুলি মসৃণভাবে চলার জন্য, অনেকগুলি কারণকে বিবেচনায় নেওয়া প্রয়োজন এবং পরিবর্তনগুলি প্রতিনিয়ত ঘটে।

রিফ্যাক্টরিং উত্তরযোগ্য কোড, কনফিগারেশন ফাইল
অভ্যন্তরীণ সেরা অভ্যাস পরিবর্তন
ঘটনা/দুর্ঘটনা বিশ্লেষণের ফলাফলের উপর ভিত্তি করে পরিবর্তন
অভ্যন্তরীণ এবং বাহ্যিক উভয় নিরাপত্তা মান পরিবর্তন করা। উদাহরণস্বরূপ, PCI DSS প্রতি বছর নতুন প্রয়োজনীয়তার সাথে আপডেট করা হয়

অবকাঠামো বৃদ্ধি এবং যাত্রা শুরু

সার্ভার/লজিক্যাল ডোমেন/ডেটা সেন্টারের সংখ্যা বেড়েছে এবং তাদের সাথে কনফিগারেশনে ত্রুটির সংখ্যা বেড়েছে। কিছু সময়ে, আমরা তিনটি দিকনির্দেশে এসেছি যেখানে কনফিগারেশন পরিচালনার বিকাশ করা দরকার:

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

এটি কয়েকটি সরঞ্জাম যোগ করার জন্য অবশেষ।

আমরা আমাদের কোড রিপোজিটরি হিসাবে গিটল্যাব সিই বেছে নিয়েছি, এর অন্তর্নির্মিত CI/CD মডিউলগুলির জন্য নয়।

গোপন ভল্ট - Hashicorp ভল্ট, সহ। মহান API এর জন্য।

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

আমাদের পছন্দ:

অণু + টেস্টিনফ্রা
উত্তরযোগ্য + টাওয়ার + AWX
সার্ভারের বিশ্ব + DITNET (নিজস্ব উন্নয়ন)
মুচি
গিটল্যাব + গিটল্যাব রানার
হাশিকর্প ভল্ট

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

"গোল্ডেন ইমেজ" থেকে সার্ভার কপি করা খারাপ!প্রধান অসুবিধা হল আপনি জানেন না যে ছবিগুলি এখন ঠিক কোন অবস্থায় আছে এবং সমস্ত পরিবর্তন সমস্ত ভার্চুয়ালাইজেশন খামারের সমস্ত ছবিতে আসবে৷
ন্যূনতম ডিফল্ট কনফিগারেশন ফাইলগুলি ব্যবহার করুন এবং অন্যান্য বিভাগের সাথে সম্মত হন যে আপনি প্রধান সিস্টেম ফাইলগুলির জন্য দায়ীউদাহরণস্বরূপ,
1. /etc/sysctl.conf খালি রাখুন, সেটিংস শুধুমাত্র /etc/sysctl.d/ এ থাকা উচিত। একটি ফাইলে আপনার ডিফল্ট, অন্যটিতে অ্যাপ্লিকেশনের জন্য কাস্টম।
2. সিস্টেমড ইউনিট সম্পাদনা করতে ওভাররাইড ফাইল ব্যবহার করুন।
সমস্ত কনফিগার টেমপ্লেট করুন এবং সেগুলি সম্পূর্ণরূপে অন্তর্ভুক্ত করুন; যদি সম্ভব হয়, প্লেবুকগুলিতে কোনও সেড বা এর অ্যানালগ নেই
কনফিগারেশন ম্যানেজমেন্ট সিস্টেম কোড রিফ্যাক্টরিং:
1. কার্যগুলিকে যৌক্তিক সত্তাগুলিতে ভেঙে ফেলুন এবং মনোলিথগুলিকে ভূমিকাগুলিতে পুনরায় লিখুন৷
2. লিন্টার ব্যবহার করুন! উত্তরযোগ্য-লিন্ট, ইয়ামল-লিন্ট, ইত্যাদি
3. আপনার পদ্ধতি পরিবর্তন করুন! নোংরামি। সিস্টেমের অবস্থা বর্ণনা করা প্রয়োজন
সমস্ত উত্তরযোগ্য ভূমিকার জন্য আপনাকে অণুতে পরীক্ষা লিখতে হবে এবং দিনে একবার রিপোর্ট তৈরি করতে হবে।
আমাদের ক্ষেত্রে, পরীক্ষার প্রস্তুতির পরে (যার মধ্যে 100 টিরও বেশি) প্রায় 70000 ত্রুটি পাওয়া গেছে। এটি ঠিক করতে কয়েক মাস লেগেছে।

আমাদের বাস্তবায়ন

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

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

সার্ভার তৈরির জন্যও অনেক অপশন রয়েছে। আমরা কাস্টম পাইথন স্ক্রিপ্টগুলি বেছে নিয়ে শেষ করেছি। এবং CI উত্তরযোগ্য জন্য:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

এই আমরা কি এসেছি, সিস্টেম বাঁচতে এবং বিকাশ অব্যাহত.

সার্ভার সেট আপ করার জন্য 17 উত্তরযোগ্য ভূমিকা। প্রতিটি ভূমিকা একটি পৃথক যৌক্তিক কাজ (লগিং, অডিটিং, ব্যবহারকারীর অনুমোদন, পর্যবেক্ষণ, ইত্যাদি) সমাধান করার জন্য ডিজাইন করা হয়েছে।
ভূমিকা পরীক্ষা. অণু + টেস্টইনফ্রা।
নিজস্ব উন্নয়ন: CMDB + অর্কেস্ট্রেটর।
সার্ভার তৈরির সময় হল ~30 মিনিট, স্বয়ংক্রিয় এবং কার্যত টাস্ক কিউ থেকে স্বাধীন।
সমস্ত বিভাগে অবকাঠামোর একই অবস্থা/নামকরণ - প্লেবুক, সংগ্রহস্থল, ভার্চুয়ালাইজেশন উপাদান।
স্ট্যান্ডার্ডের সাথে অমিলের রিপোর্ট তৈরির সাথে সার্ভারের অবস্থার দৈনিক চেক।

আমি আশা করি আমার গল্পটি তাদের যাত্রার শুরুতে যারা আছে তাদের কাজে লাগবে। আপনি কি অটোমেশন স্ট্যাক ব্যবহার করেন?

উত্স: www.habr.com