কনসাল + iptables = :3

2010 সালে কোম্পানি যুদ্ধের খেলা 50টি সার্ভার এবং একটি সাধারণ নেটওয়ার্ক মডেল ছিল: ব্যাকএন্ড, ফ্রন্টএন্ড এবং ফায়ারওয়াল। সার্ভারের সংখ্যা বাড়তে থাকে, মডেলটি আরও জটিল হয়ে ওঠে: স্টেজিং, ACL এর সাথে বিচ্ছিন্ন VLAN, তারপর VRF এর সাথে VPN, L2 এ ACL সহ VLAN, L3 এ ACL এর সাথে VRF। মাথা ঘুরছে? পরে আরো মজা হবে।

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

তিনি আপনাকে বলবেন যে এটি কীভাবে কাজ করে এবং কেন আপনার এই সিস্টেমটি ঘনিষ্ঠভাবে দেখা উচিত। ইভান আগারকভ (annmuor) কোম্পানির মিনস্ক উন্নয়ন কেন্দ্রে রক্ষণাবেক্ষণ বিভাগের অবকাঠামো নিরাপত্তা গোষ্ঠীর প্রধান। ইভান একজন SELinux ভক্ত, পার্লকে ভালোবাসেন এবং কোড লেখেন। তথ্য নিরাপত্তা গোষ্ঠীর প্রধান হিসাবে, তিনি নিয়মিত লগ, ব্যাকআপ এবং R&D নিয়ে কাজ করেন হ্যাকারদের থেকে ওয়ারগেমিংকে রক্ষা করতে এবং কোম্পানির সমস্ত গেম সার্ভারের অপারেশন নিশ্চিত করতে।

ঐতিহাসিক পটভূমি

আমরা কীভাবে এটি করেছি তা আমি আপনাকে বলার আগে, আমি আপনাকে বলব যে আমরা প্রথম স্থানে কীভাবে এসেছি এবং কেন এটির প্রয়োজন ছিল। এটি করার জন্য, আসুন 9 বছর পিছনে যাই: 2010, ওয়ার্ল্ড অফ ট্যাঙ্ক সবেমাত্র হাজির। Wargaming প্রায় 50 সার্ভার ছিল.

কোম্পানি সার্ভার বৃদ্ধি চার্ট.

আমাদের একটি নেটওয়ার্ক মডেল ছিল। সেই সময়ের জন্য এটি সর্বোত্তম ছিল।

2010 সালে নেটওয়ার্ক মডেল।

সামনের প্রান্তে খারাপ লোক আছে যারা আমাদের ভাঙতে চায়, কিন্তু এর একটি ফায়ারওয়াল আছে। ব্যাকএন্ডে কোন ফায়ারওয়াল নেই, তবে সেখানে 50টি সার্ভার রয়েছে, আমরা সেগুলি সবই জানি। সবকিছু ভাল কাজ করে.

4 বছরে, সার্ভারের বহর 100 গুণ বেড়ে 5000-এ পৌঁছেছিল। প্রথম বিচ্ছিন্ন নেটওয়ার্কগুলি উপস্থিত হয়েছিল - স্টেজিং: তারা উত্পাদনে যেতে পারেনি এবং সেখানে প্রায়শই এমন কিছু চলছিল যা বিপজ্জনক হতে পারে।

2014 সালে নেটওয়ার্ক মডেল।

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

2016 সালে, সার্ভারের সংখ্যা 8000 ছুঁয়েছে৷ ওয়ারগেমিং অন্যান্য স্টুডিওগুলিকে শুষে নিয়েছে এবং অতিরিক্ত অ্যাফিলিয়েট নেটওয়ার্কগুলি উপস্থিত হয়েছে৷ এগুলি আমাদের বলে মনে হচ্ছে, কিন্তু পুরোপুরি নয়: VLAN প্রায়শই অংশীদারদের জন্য কাজ করে না, আপনাকে VRF এর সাথে VPN ব্যবহার করতে হবে, বিচ্ছিন্নতা আরও জটিল হয়ে ওঠে৷ ACL নিরোধক মিশ্রণ বেড়েছে।

2016 সালে নেটওয়ার্ক মডেল।

2018 সালের শুরুতে, মেশিনের বহর বেড়ে 16 হয়েছে। সেখানে 000টি সেগমেন্ট ছিল এবং আমরা বাকিগুলিকে গণনা করিনি, যার মধ্যে আর্থিক ডেটা সঞ্চিত ছিল বন্ধ থাকাগুলি সহ। কনটেইনার নেটওয়ার্ক (Kubernetes), DevOps, VPN এর মাধ্যমে সংযুক্ত ক্লাউড নেটওয়ার্ক, উদাহরণস্বরূপ, একটি IVS থেকে, উপস্থিত হয়েছে। অনেক নিয়ম ছিল - এটা বেদনাদায়ক ছিল।

2018 সালে নেটওয়ার্ক মডেল এবং বিচ্ছিন্নতা পদ্ধতি।

বিচ্ছিন্নতার জন্য আমরা ব্যবহার করেছি: L2 এ ACL এর সাথে VLAN, L3 এ ACL এর সাথে VRF, VPN এবং আরও অনেক কিছু। অতিরিক্ত.

সমস্যার

সবাই ACL এবং VLAN নিয়ে থাকে। কোনো সমস্যা? এই প্রশ্নের উত্তর দেবেন হ্যারল্ড, ব্যথা লুকিয়ে।

অনেক সমস্যা ছিল, কিন্তু পাঁচটি বড় সমস্যা ছিল।

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

2018 সালে একজন নেটওয়ার্ক প্রকৌশলী এইরকম দেখতে ছিলেন যখন তিনি শুনেছিলেন: "আরো কিছু ACL দরকার।"

সমাধান

2018 এর শুরুতে, এটি সম্পর্কে কিছু করার সিদ্ধান্ত নেওয়া হয়েছিল।

ইন্টিগ্রেশনের দাম ক্রমাগত বাড়ছে। সূচনা পয়েন্ট ছিল যে বড় ডেটা সেন্টারগুলি বিচ্ছিন্ন VLAN এবং ACL সমর্থন করা বন্ধ করে দিয়েছে কারণ ডিভাইসগুলির মেমরি ফুরিয়ে গেছে।

সমাধান: আমরা মানবিক ফ্যাক্টরটি সরিয়ে দিয়েছি এবং সর্বাধিক অ্যাক্সেসের বিধান স্বয়ংক্রিয় করেছি।

নতুন নিয়ম প্রয়োগ করতে অনেক সময় লাগে। সমাধান: নিয়ম প্রয়োগের গতি বাড়ান, এটিকে বিতরণ এবং সমান্তরাল করুন। এর জন্য একটি বিতরণ করা সিস্টেমের প্রয়োজন যাতে নিয়মগুলি এক হাজার সিস্টেমে rsync বা SFTP ছাড়াই বিতরণ করা হয়।

সেগমেন্টের ভিতরে কোন ফায়ারওয়াল নেই। সেগমেন্টের মধ্যে একটি ফায়ারওয়াল আমাদের কাছে আসতে শুরু করে যখন একই নেটওয়ার্কের মধ্যে বিভিন্ন পরিষেবা উপস্থিত হয়। সমাধান: হোস্ট স্তরে একটি ফায়ারওয়াল ব্যবহার করুন - হোস্ট-ভিত্তিক ফায়ারওয়াল। আমাদের প্রায় সর্বত্র লিনাক্স আছে, এবং যেখানেই আমাদের iptables আছে, এটি একটি সমস্যা নয়।

অডিট নিয়ম সঙ্গে অসুবিধা. সমাধান: পর্যালোচনা এবং পরিচালনার জন্য সমস্ত নিয়ম এক জায়গায় রাখুন, যাতে আমরা সবকিছু অডিট করতে পারি।

অবকাঠামোর উপর নিম্ন স্তরের নিয়ন্ত্রণ। সমাধান: তাদের মধ্যে সমস্ত পরিষেবা এবং অ্যাক্সেসের একটি তালিকা নিন।

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

আমরা সব কিছু চালু করার পরে, 2019 সালে একজন নেটওয়ার্ক ইঞ্জিনিয়ার এইরকম দেখতে শুরু করেছিলেন।

দূত

আমরা সিদ্ধান্ত নিয়েছি যে পরিষেবা পরিচালকদের সাহায্যে আমরা যা কিছু পেয়েছি তা কনসালে রাখব এবং সেখান থেকে আমরা iptables নিয়ম লিখব।

কিভাবে আমরা এটা করার সিদ্ধান্ত নিয়েছি?

• আমরা সমস্ত পরিষেবা, নেটওয়ার্ক এবং ব্যবহারকারী সংগ্রহ করব।
• আসুন তাদের উপর ভিত্তি করে iptables নিয়ম তৈরি করি।
• আমরা স্বয়ংক্রিয়ভাবে নিয়ন্ত্রণ করি।
• ....
• লাভ।

কনসাল একটি দূরবর্তী API নয়, এটি প্রতিটি নোডে চলতে পারে এবং iptables এ লিখতে পারে। যা বাকি আছে তা হল স্বয়ংক্রিয় নিয়ন্ত্রণ নিয়ে আসা যা অপ্রয়োজনীয় জিনিসগুলি পরিষ্কার করবে এবং বেশিরভাগ সমস্যা সমাধান করা হবে! আমরা যেতে যেতে বাকি কাজ আউট করব.

কেন কনসাল?

নিজেকে ভালোভাবে প্রমাণ করেছেন। 2014-15 সালে, আমরা এটিকে ভল্টের ব্যাকএন্ড হিসাবে ব্যবহার করি, যেখানে আমরা পাসওয়ার্ড সংরক্ষণ করি।

ডেটা হারায় না. ব্যবহারের সময়, কনসাল একটি দুর্ঘটনার সময় ডেটা হারায়নি। এটি একটি ফায়ারওয়াল ম্যানেজমেন্ট সিস্টেমের জন্য একটি বিশাল প্লাস।

P2P সংযোগ পরিবর্তনের বিস্তারকে ত্বরান্বিত করে. P2P এর সাথে, সমস্ত পরিবর্তন দ্রুত আসে, ঘন্টার জন্য অপেক্ষা করার দরকার নেই।

সুবিধাজনক REST API। আমরা Apache ZooKeeperও বিবেচনা করেছি, কিন্তু এটির একটি REST API নেই, তাই আপনাকে ক্রাচ ইনস্টল করতে হবে।

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

Go-তে লেখা, যা Wargaming স্ট্যাকের অংশ। আমরা এই ভাষা ভালোবাসি, আমাদের অনেক গো ডেভেলপার আছে।

শক্তিশালী ACL সিস্টেম। Consul-এ, কে কী লিখবে তা নিয়ন্ত্রণ করতে আপনি ACL ব্যবহার করতে পারেন। আমরা গ্যারান্টি দিচ্ছি যে ফায়ারওয়াল নিয়মগুলি অন্য কিছুর সাথে ওভারল্যাপ করবে না এবং আমাদের এতে সমস্যা হবে না।

কিন্তু কনসাল এর অপূর্ণতা আছে.

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

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

কনসাল কিভাবে কাজ করে

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

ক্লায়েন্ট যেকোন ক্রমে সার্ভারের সাথে সংযোগ করে: একই এজেন্ট, শুধুমাত্র পতাকা সহ server = false.

এর পরে, ক্লায়েন্টরা P2P সংযোগের একটি তালিকা পায় এবং নিজেদের মধ্যে সংযোগ তৈরি করে।

বৈশ্বিক স্তরে, আমরা বেশ কয়েকটি ডেটা সেন্টার সংযুক্ত করি। তারা P2P কে সংযুক্ত করে এবং যোগাযোগ করে।

যখন আমরা অন্য ডেটা সেন্টার থেকে ডেটা পুনরুদ্ধার করতে চাই, অনুরোধটি সার্ভার থেকে সার্ভারে যায়। এই স্কিম বলা হয় সার্ফ প্রোটোকল. সার্ফ প্রোটোকল, কনসালের মতো, HashiCorp দ্বারা তৈরি করা হয়েছে।

কনসাল সম্পর্কে কিছু গুরুত্বপূর্ণ তথ্য

কনসালের কাছে এটি কীভাবে কাজ করে তা বর্ণনা করে ডকুমেন্টেশন রয়েছে। আমি শুধুমাত্র নির্বাচিত তথ্য দেব যা জানার যোগ্য।

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

আপনি অনুভূমিক স্কেলিং চান? দুঃখিত, না.

অন্য ডেটা সেন্টারে একটি অনুরোধ মাস্টার থেকে মাস্টারের দিকে যায়, এটি যে সার্ভারে এসেছে তা নির্বিশেষে। নির্বাচিত মাস্টার 100% লোড পান, ফরওয়ার্ড অনুরোধের লোড ব্যতীত। ডেটা সেন্টারের সমস্ত সার্ভারে ডেটার একটি আপ-টু-ডেট কপি থাকে, কিন্তু শুধুমাত্র একটিই সাড়া দেয়।

স্কেল করার একমাত্র উপায় হল ক্লায়েন্টে বাসি মোড সক্ষম করা।

বাসি মোডে, আপনি কোরাম ছাড়াই সাড়া দিতে পারেন। এটি এমন একটি মোড যেখানে আমরা ডেটা সামঞ্জস্য ত্যাগ করি, কিন্তু স্বাভাবিকের চেয়ে একটু দ্রুত পড়ি এবং যেকোনো সার্ভার সাড়া দেয়। স্বাভাবিকভাবেই, শুধুমাত্র মাস্টারের মাধ্যমে রেকর্ডিং।

কনসাল ডেটা সেন্টারের মধ্যে ডেটা কপি করে না. যখন একটি ফেডারেশন একত্রিত হয়, প্রতিটি সার্ভারের শুধুমাত্র নিজস্ব ডেটা থাকবে। অন্যদের জন্য, তিনি সর্বদা অন্য কারও দিকে ফিরে যান।

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

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

ACL অ্যাক্সেসের নিশ্চয়তা দেয় না (অনেক ক্ষেত্রে). ACL কাজ নাও করতে পারে কারণ এটি একটি ফেডারেশন ডেটা সেন্টারে - ACL ডেটা সেন্টারে (প্রাথমিক DC) সংরক্ষণ করা হয়। ডিসি আপনাকে উত্তর না দিলে, ACL কাজ করবে না।

একটি হিমায়িত মাস্টার পুরো ফেডারেশনকে হিমায়িত করবে. উদাহরণস্বরূপ, একটি ফেডারেশনে 10টি ডেটা সেন্টার রয়েছে এবং একটির নেটওয়ার্ক খারাপ এবং একটি মাস্টার ব্যর্থ হয়েছে৷ তার সাথে যোগাযোগকারী প্রত্যেকে একটি বৃত্তে আটকে থাকবে: একটি অনুরোধ আছে, এটির কোন উত্তর নেই, থ্রেড জমে যায়। কবে হবে তা জানার উপায় নেই, মাত্র এক-দুই ঘণ্টার মধ্যে পুরো ফেডারেশনের পতন ঘটবে। এটা সম্পর্কে আপনি কিছু করতে পারেন না.

স্থিতি, কোরাম এবং নির্বাচন একটি পৃথক থ্রেড দ্বারা পরিচালিত হয়। পুনঃনির্বাচন হবে না, স্ট্যাটাস কিছু দেখাবে না। আপনি মনে করেন যে আপনার একজন লাইভ কনসাল আছে, আপনি জিজ্ঞাসা করুন, এবং কিছুই হয় না - কোন উত্তর নেই। একই সময়ে, স্ট্যাটাস দেখায় যে সবকিছু ঠিক আছে।

আমরা এই সমস্যার সম্মুখীন হয়েছি এবং এটি এড়াতে ডেটা সেন্টারের নির্দিষ্ট অংশ পুনর্নির্মাণ করতে হয়েছে।

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

জীবন হ্যাকিং: rm -rf /var/lib/consul - এজেন্টের সমস্ত রোগের নিরাময়। যদি কিছু আপনার জন্য কাজ না করে, শুধু আপনার ডেটা মুছে দিন এবং একটি কপি থেকে ডেটা ডাউনলোড করুন। খুব সম্ভবত, কনসাল কাজ করবে।

BEFW

এখন আসুন আমরা কনসালে কি যোগ করেছি সে সম্পর্কে কথা বলি।

BEFW এর সংক্ষিপ্ত রূপ BACKEndFক্রোধWসব যখন আমি এটিতে প্রথম পরীক্ষা কমিট রাখার জন্য সংগ্রহস্থল তৈরি করি তখন আমাকে কোনওভাবে পণ্যটির নাম দিতে হয়েছিল। এই নামটি রয়ে গেছে।

নিয়ম টেমপ্লেট

নিয়মগুলি iptables সিনট্যাক্সে লেখা হয়।

• -এন BEFW
• -পি ইনপুট ড্রপ
• -একটি ইনপুট -m রাষ্ট্র - রাষ্ট্র সম্পর্কিত, প্রতিষ্ঠিত -j স্বীকার করুন
• -একটি ইনপুট -i lo -j স্বীকার করুন৷
• -একটি ইনপুট -j BEFW

সবকিছু BEFW চেইনে যায়, ছাড়া ESTABLISHED, RELATED এবং স্থানীয় হোস্ট। টেমপ্লেট যেকোনও হতে পারে, এটি একটি উদাহরণ মাত্র।

BEFW কিভাবে দরকারী?

সার্ভিস

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

কনসালের সাথে চলমান এবং নিবন্ধিত যে কোনও পরিষেবা একটি iptables নিয়মে পরিণত হয়। আমাদের কাছে এসএসএইচ - ওপেন পোর্ট 22 রয়েছে। ব্যাশ স্ক্রিপ্টটি সহজ: কার্ল এবং iptables, অন্য কিছুর প্রয়োজন নেই।

ক্লায়েন্ট

কীভাবে সবার কাছে নয়, বেছে বেছে অ্যাক্সেস খুলবেন? পরিষেবার নাম অনুসারে KV স্টোরেজে IP তালিকা যোগ করুন।

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

অ্যাক্সেস

আমরা পরিষেবা এবং ক্লায়েন্টদের সংযুক্ত করি: আমাদের একটি পরিষেবা আছে, কেভি স্টোরেজ প্রতিটির জন্য প্রস্তুত। এখন আমরা সবাইকে নয়, বেছে বেছে অ্যাক্সেস দিই।

গ্রুপ

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

আসুন সংযোগ করি: এখন আমরা P2P এর জন্য বিশেষভাবে নয়, একটি সম্পূর্ণ গ্রুপ বা একাধিক গ্রুপের জন্য SSH খুলতে পারি। একইভাবে, TTL আছে - আপনি একটি গ্রুপে যোগ করতে পারেন এবং সাময়িকভাবে গ্রুপ থেকে সরাতে পারেন।

মিশ্রণ

আমাদের সমস্যা মানব ফ্যাক্টর এবং অটোমেশন. এখন পর্যন্ত আমরা এইভাবে সমাধান করেছি।

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

আমরা befw-sync লিখেছি, একটি সহজ সমাধান যা ডেটা স্থানান্তর করতে সাহায্য করে। প্রথমত, সিঙ্ক কুকিজ puppetdb দ্বারা অ্যাক্সেস করা হয়। সেখানে একটি HTTP API কনফিগার করা আছে: আমরা অনুরোধ করি আমাদের কী পরিষেবা আছে, কী করা দরকার। এরপর তারা কনসালকে অনুরোধ করেন।

ইন্টিগ্রেশন আছে? হ্যাঁ: তারা নিয়ম লিখেছিল এবং পুল অনুরোধগুলি গ্রহণ করার অনুমতি দিয়েছে। আপনি একটি নির্দিষ্ট পোর্ট প্রয়োজন বা কিছু গ্রুপে একটি হোস্ট যোগ করুন? অনুরোধ টানুন, পর্যালোচনা করুন - আর নয় "অন্যান্য 200টি ACL খুঁজুন এবং এটি সম্পর্কে কিছু করার চেষ্টা করুন।"

অপ্টিমাইজেশান

একটি খালি নিয়ম চেইন সহ লোকালহোস্টকে পিং করতে 0,075 ms লাগে।

আসুন এই চেইনে 10 iptables ঠিকানা যোগ করি। ফলস্বরূপ, পিং 000 গুণ বৃদ্ধি পাবে: iptables সম্পূর্ণরূপে লিনিয়ার, প্রতিটি ঠিকানা প্রক্রিয়াকরণ কিছু সময় নেয়।

একটি ফায়ারওয়ালের জন্য যেখানে আমরা হাজার হাজার ACL স্থানান্তর করি, আমাদের অনেক নিয়ম রয়েছে এবং এটি লেটেন্সি প্রবর্তন করে। এটি গেমিং প্রোটোকলের জন্য খারাপ।

কিন্তু যদি আমরা রাখি ipset এ 10 ঠিকানা পিং এমনকি কমে যাবে.

বিন্দু হল যে ipset এর জন্য “O” (অ্যালগরিদম জটিলতা) সর্বদা 1 এর সমান, যত নিয়মই থাকুক না কেন। সত্য, একটি সীমাবদ্ধতা আছে - 65535 টির বেশি নিয়ম থাকতে পারে না। আপাতত আমরা এটির সাথে বাস করি: আপনি সেগুলিকে একত্রিত করতে পারেন, তাদের প্রসারিত করতে পারেন, একটিতে দুটি আইপসেট তৈরি করতে পারেন।

স্টোরেজ

পুনরাবৃত্তি প্রক্রিয়ার একটি যৌক্তিক ধারাবাহিকতা হল ipset-এ পরিষেবার জন্য ক্লায়েন্টদের সম্পর্কে তথ্য সংরক্ষণ করা।

এখন আমাদের একই এসএসএইচ আছে, এবং আমরা একসাথে 100টি আইপি লিখি না, তবে যে আইপসেটের সাথে আমাদের যোগাযোগ করতে হবে তার নাম সেট করি এবং নিম্নলিখিত নিয়মগুলি DROP. এটি একটি নিয়মে রূপান্তরিত হতে পারে "কে এখানে নেই, ড্রপ", তবে এটি আরও স্পষ্ট।

এখন আমরা নিয়ম এবং সেট আছে. মূল কাজ হল নিয়ম লেখার আগে একটি সেট তৈরি করা, কারণ অন্যথায় iptables নিয়ম লিখবে না।

সাধারণ পরিকল্পনা

একটি ডায়াগ্রাম আকারে, আমি যা বলেছি তা এইরকম দেখাচ্ছে।

আমরা পাপেটের প্রতি প্রতিশ্রুতিবদ্ধ, সবকিছুই হোস্টের কাছে পাঠানো হয়, এখানে পরিষেবা, সেখানে ipset, এবং যে কেউ সেখানে নিবন্ধিত নয় তাকে অনুমতি দেওয়া হয় না।

অস্বীকার অনুমতি

দ্রুত বিশ্বকে বাঁচাতে বা কাউকে দ্রুত অক্ষম করতে, সমস্ত চেইনের শুরুতে আমরা দুটি আইপসেট তৈরি করেছি: rules_allow и rules_deny. কিভাবে এটা কাজ করে?

উদাহরণস্বরূপ, কেউ বট দিয়ে আমাদের ওয়েবে একটি লোড তৈরি করে। পূর্বে, আপনাকে লগ থেকে তার আইপি খুঁজে বের করতে হবে, নেটওয়ার্ক ইঞ্জিনিয়ারদের কাছে নিয়ে যেতে হবে, যাতে তারা ট্রাফিকের উৎস খুঁজে বের করতে পারে এবং তাকে নিষিদ্ধ করতে পারে। এখন অন্যরকম লাগছে।

আমরা এটি কনসালের কাছে পাঠাই, 2,5 সেকেন্ড অপেক্ষা করুন এবং এটি হয়ে গেছে। যেহেতু কনসাল P2P এর মাধ্যমে দ্রুত বিতরণ করে, তাই এটি বিশ্বের যে কোনো প্রান্তে সর্বত্র কাজ করে।

একবার আমি ফায়ারওয়ালের ভুলের কারণে WOT পুরোপুরি বন্ধ করে দিয়েছিলাম। rules_allow - এই ধরনের মামলার বিরুদ্ধে এটি আমাদের বীমা। যদি আমরা ফায়ারওয়ালের সাথে কোথাও ভুল করে থাকি, কোথাও কিছু ব্লক করা হয়, আমরা সর্বদা একটি শর্তসাপেক্ষ পাঠাতে পারি 0.0/0দ্রুত সবকিছু নিতে। পরে আমরা হাত দিয়ে সব ঠিক করব।

অন্যান্য সেট

আপনি স্থান অন্য কোনো সেট যোগ করতে পারেন $IPSETS$.

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

ব্যবহারকারীদের

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

আমরা কি করেছিলাম? ঠিকানা পাওয়ার মুহূর্তে আমরা আটকে গেলাম। সাধারণত এটি dot1x, Wi-Fi বা VPN - সবকিছু RADIUS এর মাধ্যমে যায়। প্রতিটি ব্যবহারকারীর জন্য, আমরা ব্যবহারকারীর নাম অনুসারে একটি গ্রুপ তৈরি করি এবং এটিতে একটি TTL দিয়ে একটি আইপি রাখি যা তার dhcp.lease-এর সমান - এটি মেয়াদ শেষ হওয়ার সাথে সাথে নিয়মটি অদৃশ্য হয়ে যাবে।

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

অন্তরণ

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

স্কিমটি দ্রুত এবং সহজভাবে কাজ করে: আমরা সার্ভার থেকে সমস্ত ACL সরিয়ে ফেলি, হার্ডওয়্যার আনলোড করি এবং বিচ্ছিন্ন VLAN-এর সংখ্যা কমিয়ে দিই।

অখণ্ডতা নিয়ন্ত্রণ

পূর্বে, আমাদের একটি বিশেষ ট্রিগার ছিল যেটি রিপোর্ট করা হয়েছিল যখন কেউ ফায়ারওয়ালের নিয়ম ম্যানুয়ালি পরিবর্তন করে। আমি ফায়ারওয়াল নিয়ম চেক করার জন্য একটি বিশাল লিন্টার লিখছিলাম, এটি কঠিন ছিল। সততা এখন BEFW দ্বারা নিয়ন্ত্রিত। তিনি উদ্যোগের সাথে নিশ্চিত করেন যে তিনি যে নিয়মগুলি তৈরি করেন তা পরিবর্তন না হয়। যদি কেউ ফায়ারওয়ালের নিয়ম পরিবর্তন করে, তবে এটি সবকিছুকে আবার পরিবর্তন করবে। "আমি দ্রুত একটি প্রক্সি সেট আপ করেছি যাতে আমি বাড়ি থেকে কাজ করতে পারি"—এরকম আর কোন বিকল্প নেই।

BEFW পরিষেবাগুলি থেকে ipset নিয়ন্ত্রণ করে এবং befw.conf-এ তালিকাভুক্ত করে, BEFW চেইনের পরিষেবার নিয়ম৷ কিন্তু এটি অন্যান্য চেইন এবং নিয়ম এবং অন্যান্য ipsets নিরীক্ষণ করে না।

ক্র্যাশ সুরক্ষা

BEFW সর্বদা সর্বশেষ পরিচিত ভাল অবস্থা সরাসরি state.bin বাইনারি কাঠামোতে সঞ্চয় করে। যদি কিছু ভুল হয়ে যায়, এটি সর্বদা এই state.bin-এ ফিরে আসে।

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

জটিল পরিস্থিতিতে, এটি একটি গ্যারান্টি যে আমাদের কাছে একটি কার্যকরী ফায়ারওয়াল থাকবে। আমরা সমস্ত ধূসর নেটওয়ার্ক খুলি এই আশায় যে অ্যাডমিন এসে এটি ঠিক করবেন। কোন দিন আমি এটি কনফিগারে রাখব, কিন্তু এখন আমাদের কাছে তিনটি ধূসর নেটওয়ার্ক রয়েছে: 10/8, 172/12 এবং 192.168/16। আমাদের কনসালের মধ্যে, এটি একটি গুরুত্বপূর্ণ বৈশিষ্ট্য যা আমাদের আরও বিকাশে সহায়তা করে।

ডেমো: প্রতিবেদনের সময়, ইভান BEFW এর ডেমো মোড প্রদর্শন করে। বিক্ষোভ দেখা সহজ видео. ডেমো সোর্স কোড উপলব্ধ গিটহাবে.

pitfalls

আমরা যে বাগগুলির সম্মুখীন হয়েছি সেগুলি সম্পর্কে আমি আপনাকে বলব৷

ipset যোগ সেট 0.0.0.0/0। আপনি ipset এ 0.0.0.0/0 যোগ করলে কি হবে? সব আইপি যোগ করা হবে? ইন্টারনেট অ্যাক্সেস পাওয়া যাবে?

না, আমরা একটি বাগ পাব যা আমাদের দুই ঘন্টা ডাউনটাইম খরচ করে। তাছাড়া, বাগটি 2016 সাল থেকে কাজ করেনি, এটি RedHat Bugzilla-এ #1297092 নম্বরের অধীনে অবস্থিত, এবং আমরা দুর্ঘটনাক্রমে এটি খুঁজে পেয়েছি - একটি বিকাশকারীর প্রতিবেদন থেকে।

এটা এখন BEFW-তে কঠোর নিয়ম 0.0.0.0/0 দুটি ঠিকানায় পরিণত হয়: 0.0.0.0/1 и 128.0.0.0/1.

ipset রিস্টোর সেট < ফাইল। ipset কি করে যখন আপনি এটি করতে বলেন restore? আপনি কি মনে করেন এটি iptables হিসাবে একই কাজ করে? এটা কি ডেটা পুনরুদ্ধার করবে?

এরকম কিছুই নেই - এটি একটি মার্জ করে, এবং পুরানো ঠিকানাগুলি কোথাও যায় না, আপনি অ্যাক্সেস ব্লক করবেন না।

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

কনসাল কেভি get -datacenter=অন্যান্য। আমি যেমন বলেছি, আমরা মনে করি আমরা কিছু ডেটা চাইছি, কিন্তু আমরা হয় ডেটা বা একটি ত্রুটি পাব। আমরা স্থানীয়ভাবে কনসালের মাধ্যমে এটি করতে পারি, তবে এই ক্ষেত্রে উভয়ই জমে যাবে।

স্থানীয় কনসাল ক্লায়েন্ট হল HTTP API-এর উপর একটি মোড়ক। কিন্তু এটি কেবল হ্যাং হয় এবং Ctrl+C, বা Ctrl+Z, বা অন্য কিছুতে সাড়া দেয় না, শুধুমাত্র kill -9 পরবর্তী কনসোলে। আমরা যখন একটি বড় ক্লাস্টার তৈরি করছিলাম তখন আমরা এটির সম্মুখীন হয়েছিলাম। কিন্তু আমাদের কাছে এখনও কোনো সমাধান নেই; আমরা কনসালে এই ত্রুটি ঠিক করার প্রস্তুতি নিচ্ছি।

কনসাল নেতা সাড়া দিচ্ছেন না। ডেটা সেন্টারে আমাদের মাস্টার সাড়া দিচ্ছেন না, আমরা মনে করি: "সম্ভবত পুনঃনির্বাচন অ্যালগরিদম এখন কাজ করবে?"

না, এটি কাজ করবে না, এবং পর্যবেক্ষণ কিছুই দেখাবে না: কনসাল বলবে যে একটি প্রতিশ্রুতি সূচক আছে, একজন নেতা পাওয়া গেছে, সবকিছু ঠিক আছে।

কিভাবে আমরা এই সঙ্গে মোকাবিলা করবেন? service consul restart প্রতি ঘন্টায় ক্রোনে। আপনার যদি 50টি সার্ভার থাকে তবে কোন বড় ব্যাপার নয়। যখন তাদের মধ্যে 16 থাকবে, আপনি বুঝতে পারবেন এটি কীভাবে কাজ করে।

উপসংহার

ফলস্বরূপ, আমরা নিম্নলিখিত সুবিধাগুলি পেয়েছি:

• সমস্ত লিনাক্স মেশিনের 100% কভারেজ।
• দ্রুততা.
• অটোমেশন।
• আমরা হার্ডওয়্যার এবং নেটওয়ার্ক ইঞ্জিনিয়ারদের দাসত্ব থেকে মুক্ত করেছি।
• একীকরণের সম্ভাবনা দেখা দিয়েছে যা প্রায় সীমাহীন: এমনকি কুবারনেটসের সাথে, এমনকি অ্যানসিবলের সাথে, এমনকি পাইথনের সাথেও।

Минусы: কনসাল, যার সাথে আমাদের এখন বাস করতে হবে, এবং ত্রুটির খুব উচ্চ মূল্য। উদাহরণস্বরূপ, একবার সন্ধ্যা 6 টায় (রাশিয়ায় প্রধান সময়) আমি নেটওয়ার্কের তালিকায় কিছু সম্পাদনা করছিলাম। আমরা তখন শুধু BEFW-তে নিরোধক তৈরি করছিলাম। আমি কোথাও ভুল করেছি, মনে হচ্ছে আমি ভুল মাস্ক নির্দেশ করেছি, কিন্তু সবকিছু দুই সেকেন্ডের মধ্যে পড়ে গেছে। মনিটরিং আলোকিত হয়, দায়িত্বে থাকা সহায়তাকারী ব্যক্তি দৌড়ে আসে: "আমাদের কাছে সবকিছু আছে!" ডিপার্টমেন্টের প্রধান ধূসর হয়ে গেলেন যখন তিনি ব্যবসাকে ব্যাখ্যা করলেন কেন এটি ঘটেছে।

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

খরচ। আমি একা 400 ঘন্টার জন্য কোড লিখেছিলাম। আমার 4 জনের দল প্রত্যেকের জন্য প্রতি মাসে 10 ঘন্টা ব্যয় করে। যেকোনো নতুন প্রজন্মের ফায়ারওয়ালের দামের তুলনায়, এটি বিনামূল্যে।

পরিকল্পনা সমূহ. দীর্ঘমেয়াদী পরিকল্পনা হল কনসালকে প্রতিস্থাপন বা পরিপূরক করার জন্য বিকল্প পরিবহন খুঁজে বের করা। সম্ভবত এটি কাফকা বা অনুরূপ কিছু হবে। তবে আগামী বছরগুলোতে আমরা কনসাল থাকব।

তাৎক্ষণিক পরিকল্পনা: Fail2ban এর সাথে একীকরণ, পর্যবেক্ষণ সহ, nftables সহ, ​​সম্ভবত অন্যান্য বিতরণ, মেট্রিক্স, উন্নত পর্যবেক্ষণ, অপ্টিমাইজেশানের সাথে। Kubernetes সমর্থন এছাড়াও পরিকল্পনার কোথাও আছে, কারণ এখন আমাদের বেশ কয়েকটি ক্লাস্টার এবং ইচ্ছা আছে।

পরিকল্পনা থেকে আরো:

• ট্র্যাফিকের অসঙ্গতির জন্য অনুসন্ধান করুন;
• নেটওয়ার্ক মানচিত্র ব্যবস্থাপনা;
• Kubernetes সমর্থন;
• সমস্ত সিস্টেমের জন্য প্যাকেজ একত্রিত করা;
• ওয়েব-ইউআই।

আমরা ক্রমাগত কনফিগারেশন প্রসারিত, মেট্রিক্স এবং অপ্টিমাইজেশান বাড়ানোর জন্য কাজ করছি।

প্রকল্পে যোগদান করুন। প্রকল্পটি শান্ত হতে দেখা গেছে, কিন্তু, দুর্ভাগ্যবশত, এটি এখনও একটি এক ব্যক্তির প্রকল্প। আসো GitHub এবং কিছু করার চেষ্টা করুন: প্রতিশ্রুতি দিন, পরীক্ষা করুন, কিছু প্রস্তাব করুন, আপনার মূল্যায়ন দিন।

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

উত্স: www.habr.com