YAML Formatter

ব্রাউজারেই তাৎক্ষণিক YAML ফরম্যাট ও যাচাই করুন

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

YAML (YAML Ain't Markup Language) প্রায় প্রতিটি আধুনিক সফটওয়্যার প্রকল্পে ব্যবহৃত হয়: GitHub Actions ওয়ার্কফ্লো, Kubernetes ম্যানিফেস্ট, Docker Compose ফাইল, Ansible playbook, Helm chart, CI/CD কনফিগারেশন এবং অ্যাপ্লিকেশন কনফিগ ফাইলে। এটি ডিজাইন করা হয়েছে মানুষের পড়ার সুবিধার জন্য, কিন্তু এর ইন্ডেন্টেশন-সংবেদনশীলতা এবং বিশেষ-অক্ষরের খুঁটিনাটির কারণে অবৈধ YAML লেখা আশ্চর্যজনকভাবে সহজ — যা কেবল রানটাইমে গিয়ে ব্যর্থ হয়, তখন অনেক দেরি হয়ে যায়। একটি লাইভ ফরম্যাটার সেই এররগুলো কয়েক সেকেন্ডেই ধরে ফেলে।

সাধারণ YAML এরর এবং যাচাইকারী যেভাবে ধরে

সবচেয়ে সাধারণ YAML ভুল হলো স্পেসের বদলে ট্যাব ব্যবহার করা। YAML ইন্ডেন্টেশনে ট্যাব অক্ষর নিষিদ্ধ করে — বেশিরভাগ টেক্সট এডিটরে এগুলো স্পেসের মতোই দেখায় কিন্তু সাথে সাথেই পার্স ব্যর্থ করে দেয়। যাচাইকারী এটি ধরে এবং ঠিক কোন লাইনে ট্যাব আছে তা বলে দেয়। দ্বিতীয় সবচেয়ে সাধারণ ভুল হলো মানের মধ্যে উদ্ধৃতিবিহীন কোলন: title: Hello: World দ্ব্যর্থক — পার্সার এটিকে একটি নেস্টেড কী হিসেবে দেখে। মানটি উদ্ধৃত করুন: title: "Hello: World"। তৃতীয়টি হলো অসঙ্গতিপূর্ণ ইন্ডেন্টেশন: কোনো ব্লক এক জায়গায় ২ স্পেস এবং অন্য জায়গায় ৩ স্পেস দিয়ে ইন্ডেন্ট করা হলে পার্সার নেস্টিং স্তর ভুল বুঝতে পারে।

অন্যান্য সাধারণ এরর: একই ম্যাপিংয়ে ডুপ্লিকেট কী (YAML 1.1-এ প্রযুক্তিগতভাবে অনুমোদিত কিন্তু 1.2-তে অবৈধ, এবং বেশিরভাগ পার্সার প্রত্যাখ্যান করে); কোলনের পরে স্পেস না থাকা (key:value অবৈধ, key: value দরকার); অ্যাংকর ও অ্যালিয়াসের ভুল ব্যবহার; এবং ইমপ্লিসিট টাইপ কোয়ার্শনের চমক (YAML 1.1 পার্সারে yes স্ট্রিং বুলিয়ান true হয়ে যায়)। যাচাইকারী এগুলোর প্রতিটি স্পষ্ট ভাষায় জানায়, শুধু একটি কাঁচা পার্সার এরর ডাম্প নয়।

YAML থেকে JSON রূপান্তর — কখন এবং কেন

JSON এবং YAML শব্দার্থগতভাবে সমতুল্য ডেটা ফরম্যাট (কয়েকটি ব্যতিক্রম বাদে)। YAML হলো JSON-এর একটি সুপারসেট — বৈধ JSON একইসাথে বৈধ YAML-ও। YAML থেকে JSON রূপান্তর কাজে লাগে যখন আপনি এমন টুল বা API-এর সাথে কাজ করেন যা কেবল JSON গ্রহণ করে, অথবা যখন আপনি একটি YAML কনফিগ ফাইল কোয়েরি করতে jq ব্যবহার করতে চান (jq JSON-এর ওপর কাজ করে)। “Copy as JSON” বাটন আপনার YAML পার্স করে এবং ২-স্পেস ইন্ডেন্টেশনসহ ফরম্যাট করা JSON-এ সিরিয়ালাইজ করে।

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

YAML ফরম্যাটার বনাম yamllint, YAML Lint ও YAML Checker

yamllint হলো YAML লিন্টিংয়ের গোল্ড স্ট্যান্ডার্ড CLI টুল — পুঙ্খানুপুঙ্খ, কনফিগারযোগ্য এবং CI পাইপলাইনে ব্যবহৃত। কিন্তু এতে Python, pip এবং একটি টার্মিনাল লাগে, যা টিম সদস্যের মেশিনে বা ব্রাউজার পরিবেশে দ্রুত যাচাইয়ের জন্য অসুবিধাজনক। YAML Lint (yamllint.com) সবচেয়ে জনপ্রিয় অনলাইন বিকল্প কিন্তু শুধু এরর দেখায় — কোনো ফরম্যাটিং নেই, সিনট্যাক্স হাইলাইটিং নেই, JSON রূপান্তর নেই। YAML Checker (yamlchecker.com) ফরম্যাট ও যাচাই করে কিন্তু এতে হাইলাইটিং ছাড়া একটি সাধারণ টেক্সট-এরিয়া আছে এবং JSON আউটপুট নেই। Transform.tools YAML থেকে JSON রূপান্তর করে কিন্তু লাইভ যাচাই নেই।

এই ফরম্যাটার সেই সব সক্ষমতা এক জায়গায় একত্র করে: এরর ব্যাখ্যাসহ লাইভ যাচাই, সিনট্যাক্স হাইলাইটিংসহ ফরম্যাট করা আউটপুট, এক-ক্লিকে JSON রূপান্তর এবং মাল্টি-ডকুমেন্ট সমর্থন — সম্পূর্ণভাবে আপনার ব্রাউজারে কোনো ব্যাকএন্ড ছাড়াই চলে। যেসব ডেভেলপার টুল ইনস্টল বা সার্ভিসে সাইন আপ করতে চান না, তাদের জন্য এটি “এই YAML কি বৈধ?” থেকে “এই যে ফরম্যাট করা, এরর-মুক্ত সংস্করণ” পর্যন্ত পৌঁছানোর দ্রুততম পথ।

বাস্তব ব্যবহার — Kubernetes, GitHub Actions, Docker Compose

Kubernetes ব্যবহারকারীদের জন্য: kubectl apply দিয়ে প্রয়োগ করার আগে আপনার ম্যানিফেস্ট পেস্ট করুন যাতে সিনট্যাক্স এরর আগেভাগেই ধরা পড়ে। একটি Pod spec বা Service ডেফিনিশনে একটিমাত্র ইন্ডেন্টেশন ভুল হলে kubectl একটি দুর্বোধ্য এরর দিয়ে ব্যর্থ হয়; এখানে আগেভাগে ধরলে সময় বাঁচে। GitHub Actions ব্যবহারকারীদের জন্য: কমিট করার আগে আপনার .github/workflows/*.yml ফাইল যাচাই করতে পেস্ট করুন। ত্রুটিপূর্ণ ওয়ার্কফ্লো নীরবে ব্যর্থ হয় (অ্যাকশনটি শুধু চলে না) এবং GitHub UI-তে সেগুলো ডিবাগ করা ধীর। Docker Compose ব্যবহারকারীদের জন্য: docker compose up চালানোর আগে আপনার docker-compose.yml যাচাই করুন — বিশেষত মাল্টি-সার্ভিস ফাইলের জন্য গুরুত্বপূর্ণ, যেখানে নেস্টেড সার্ভিস ডেফিনিশনের এরর ধরা কঠিন।

Ansible ব্যবহারকারীদের জন্য: ansible-playbook চালানোর আগে YAML গঠন যাচাই করতে playbook, inventory ফাইল বা variable ফাইল পেস্ট করুন। Helm chart লেখকদের জন্য: আপনার values.yaml বা chart টেমপ্লেট যাচাই করুন। YAML-এ CI/CD কনফিগারেশন লিখছেন এমন যে কারো জন্য (GitLab CI, CircleCI, Bitbucket Pipelines, Travis CI): কনফিগটি পেস্ট করুন এবং পুশ করার আগে যাচাই করুন। এই সব ক্ষেত্রে একটি অবৈধ YAML ফাইলের মূল্য হলো একটি ব্যর্থ বিল্ড বা ডিপ্লয়মেন্ট — এখানে আগেভাগে ধরা সবসময়ই দ্রুততর।

YAML-এর উৎপত্তি, দর্শন এবং “নরওয়ে সমস্যা”

YAML — “YAML Ain't Markup Language”-এর একটি রিকার্সিভ সংক্ষিপ্ত রূপ (মূলত “Yet Another Markup Language”, যখন Clark Evans এবং Ingy döt Net ২০০১ সালে এটি তৈরি করেন) — একটিমাত্র মূলনীতিকে ঘিরে ডিজাইন করা হয়েছিল: ন্যূনতম যতিচিহ্নে মানুষের পড়ার উপযোগিতা। XML যেখানে কনটেন্টকে অ্যাঙ্গেল-ব্র্যাকেট ট্যাগে মুড়ে রাখত এবং JSON প্রতিটি কী-এর চারপাশে উদ্ধৃতি দাবি করত, YAML সেখানে সাধারণ টেক্সট, ইন্ডেন্টেশন এবং কোলন ব্যবহার করত। ফলাফল হলো এমন কনফিগ যা প্রায় গদ্যের মতো পড়া যায়। ২০০৯ সালে প্রকাশিত YAML 1.2 একটি গুরুত্বপূর্ণ সম্পর্ক আনুষ্ঠানিক করে: প্রতিটি বৈধ JSON ডকুমেন্ট একইসাথে বৈধ YAML 1.2-ও, যা YAML-কে JSON-এর একটি কঠোর সুপারসেটে পরিণত করে এবং আধুনিক সফটওয়্যারের দুটি সবচেয়ে সাধারণ সিরিয়ালাইজেশন ফরম্যাটকে একীভূত করে।

সেই পরিচ্ছন্ন ডিজাইন-ইতিহাসের সাথে আসে একটি সতর্কবার্তার গল্প, যা নরওয়ে সমস্যা (Norway Problem) নামে পরিচিত। YAML 1.1-এ — PyYAML, Ruby-র Psych এবং ২০১০-এর আগে লেখা বেশিরভাগ YAML লাইব্রেরি যে সংস্করণটি বাস্তবায়ন করত — yes, no, on, off, true এবং false-এর মতো খালি শব্দ নীরবে বুলিয়ানে রূপান্তরিত হতো। একটি Kubernetes কনফিগ যা নরওয়ের ISO কান্ট্রি কোড স্ট্রিং NO হিসেবে তালিকাভুক্ত করত, তা বুলিয়ান false হিসেবে পার্স হয়ে নীরবে কনফিগারেশন নষ্ট করে দিত। একই ফাঁদ ON (বুলিয়ান true), off (বুলিয়ান false) এবং আরও কয়েক ডজন নিরীহ স্ট্রিংকে ধরত। YAML 1.2 এটি ঠিক করেছে ইমপ্লিসিট বুলিয়ান রূপান্তরকে ঠিক true ও false-এ সীমিত করে — কিন্তু এই সমাধান কেবল সেই পার্সারগুলোতে প্রযোজ্য যেগুলো 1.2 বাস্তবায়ন করে, আর বাস্তব-জগতের বড় অংশের টুলিং এখনও ভেতরে 1.1 ব্যবহার করে। সবচেয়ে নিরাপদ চর্চা হলো এমন যেকোনো স্ট্রিং মান উদ্ধৃত করা যা বুলিয়ান হিসেবে ভুল বোঝা যেতে পারে।

নরওয়ে সমস্যা হলো একটি কারণ যার জন্য YAML স্কেলে ডেভেলপারদের চমকে দেওয়ার সুনাম অর্জন করেছে। এর ইমপ্লিসিট টাইপ সিস্টেম — যেখানে 1.0 একটি ফ্লোট হয়ে যায়, 0x1F একটি ইন্টিজার হয়ে যায় এবং 2024-01-01 একটি ডেট অবজেক্ট হয়ে যায় — YAML-কে মানুষের জন্য অভিব্যক্তিময় কিন্তু মেশিনের জন্য বিপজ্জনক করে তোলে। আপনার পার্সার কোন সংস্করণ বাস্তবায়ন করে তা বোঝা ঐচ্ছিক জ্ঞান নয়; এটি পোর্টেবল কনফিগ লেখার ভিত্তি। এখানকার ফরম্যাটারটি YAML 1.2 শব্দার্থবিদ্যা লক্ষ্য করে, যা Kubernetes, Go-র yaml.v3 এবং Rust-এর serde-yaml-এর সাথে সামঞ্জস্যপূর্ণ।

YAML নিরাপত্তা দুর্বলতা — কেন নিরাপদ পার্সিং জরুরি

YAML-এর সবচেয়ে বিপজ্জনক বৈশিষ্ট্যটি টিউটোরিয়ালে খুব কমই উল্লেখ করা হয়: পার্সিংয়ের সময় নির্বিচার কোড এক্সিকিউশন। PyYAML, প্রভাবশালী Python YAML লাইব্রেরি, !! ট্যাগ সিনট্যাক্সের মাধ্যমে কাস্টম টাইপ কনস্ট্রাক্টর সমর্থন করে। !!python/object/apply:os.system ["rm -rf /"] ধারণকারী একটি YAML ডকুমেন্ট yaml.load() দিয়ে পার্স করার মুহূর্তেই সেই শেল কমান্ডটি চালিয়ে দেবে — কোনো ব্যবহারকারীর হস্তক্ষেপ নেই, কোনো নিশ্চিতকরণ নেই। ডিফল্ট লোডার দিয়ে অবিশ্বস্ত YAML লোড করা কার্যত eval()-এর সমতুল্য। সমাধান সবসময় yaml.safe_load() ব্যবহার করা, যা কাস্টম কনস্ট্রাক্টর সম্পূর্ণ নিষ্ক্রিয় করে এবং পার্সিংকে স্ট্যান্ডার্ড YAML টাইপে সীমিত করে। PyYAML বছরের পর বছর এ নিয়ে ডেপ্রিকেশন সতর্কতা দিয়েছে, এবং Python 3.9+ পছন্দটি সচেতন করতে একটি স্পষ্ট Loader আর্গুমেন্ট দাবি করে — কিন্তু খালি yaml.load() ব্যবহারকারী লিগ্যাসি কোড এখনও ব্যাপক।

একই শ্রেণির দুর্বলতা Ruby-র YAML (Psych)-এও দেখা গিয়েছিল এবং রেকর্ডে থাকা সবচেয়ে উল্লেখযোগ্য Rails নিরাপত্তা ঘটনাগুলোর একটির জন্ম দিয়েছিল। ২০১৩ সালের জানুয়ারিতে গবেষক Charlie Somerville Rails-এ একটি YAML ডিসিরিয়ালাইজেশন দুর্বলতা প্রকাশ করেন, যা একটি রিকোয়েস্ট প্যারামিটার হিসেবে সাজানো YAML পেলোড পাঠিয়ে রিমোট কোড এক্সিকিউশনের সুযোগ দিত। সে সময় শিরোনাম হওয়া Rails mass-assignment দুর্বলতা কেবল গল্পের একটি অংশ ছিল; YAML ডিসিরিয়ালাইজেশন RCE ছিল আরও গুরুতর আবিষ্কার। SnakeYAML, ব্যাপকভাবে ব্যবহৃত Java YAML লাইব্রেরি, একাধিক হাই-প্রোফাইল CVE-এর উৎস হয়েছে — যার মধ্যে CVE-2022-1471, যা Spring Boot-কে প্রভাবিত করেছিল এবং বাস্তবে শোষিত হয়েছিল কারণ অ্যাপ্লিকেশনগুলো ব্যবহারকারীর ইনপুট থেকে YAML গ্রহণ করে সরাসরি পার্সারে পাঠাত। প্যাটার্নটি সুসংগত: টাইপ কনস্ট্রাক্টর সমর্থনকারী YAML পার্সার হলো ট্রিগার হওয়ার অপেক্ষায় থাকা ডিসিরিয়ালাইজেশন গ্যাজেট।

ব্যবহারিক নিয়মগুলো সহজ। যেকোনো বাহ্যিক উৎস থেকে আসা কনটেন্টে কখনও একটি YAML পার্সারের অনিরাপদ লোডার চালাবেন না — ব্যবহারকারীর ইনপুট, API রেসপন্স, ব্যবহারকারীর আপলোড করা ফাইল, বা অবিশ্বস্ত রিপোজিটরি থেকে টানা কনফিগ। সবসময় নিরাপদ লোডিং API ব্যবহার করুন (Python-এ yaml.safe_load(), Ruby-তে Psych.safe_load, Java-তে SnakeYAML-কে SafeConstructor-এ সীমিত রাখুন)। একটি ব্রাউজার পরিবেশে — এই ফরম্যাটার যেভাবে কাজ করে — এখানে ব্যবহৃত JavaScript YAML পার্সারের হোস্ট-ল্যাঙ্গুয়েজ অবজেক্ট নির্মাণের কোনো ধারণা নেই, তাই এই আক্রমণগুলো প্রযোজ্য নয়। কিন্তু বাহ্যিক উৎস থেকে YAML প্রসেস করা যেকোনো সার্ভার-সাইড পাইপলাইনের সেই YAML-কে অবিশ্বস্ত ইনপুট হিসেবে বিবেচনা করা এবং লাইব্রেরি স্তরে নিরাপদ পার্সিং প্রয়োগ করা উচিত।

YAML বনাম JSON বনাম TOML — সঠিক ফরম্যাট বেছে নেওয়া

YAML-এর শক্তি বাস্তব: এটি ইনলাইন কমেন্ট সমর্থন করে (# this is a comment — একমাত্র ব্যাপকভাবে ব্যবহৃত সিরিয়ালাইজেশন ফরম্যাট যা এটি করে), লিটারাল ব্লক (|) ও ফোল্ডেড ব্লক (>) স্টাইলে মাল্টিলাইন স্ট্রিং, DRY কনফিগারেশনের জন্য অ্যাংকর ও অ্যালিয়াস, এবং এমন একটি সিনট্যাক্স যা নেস্টেড কাঠামোর জন্য স্বাভাবিকভাবে পড়া যায়। এই বৈশিষ্ট্যগুলো একে ক্লাউড ও কন্টেইনার জগতে প্রভাবশালী ফরম্যাটে পরিণত করে — Kubernetes, GitHub Actions, GitLab CI, CircleCI, Ansible এবং Docker Compose সবাই YAML-কে তাদের প্রাথমিক কনফিগারেশন ভাষা হিসেবে ব্যবহার করে। ফরম্যাটটি মানুষের জন্য ডিজাইন করা, আর বড় কনফিগের ক্ষেত্রে এটি সেই ডিজাইনের যোগ্যতা প্রমাণ করে।

YAML-এর দুর্বলতাও সমানভাবে বাস্তব। তাৎপর্যপূর্ণ হোয়াইটস্পেস মানে একটি অদৃশ্য অতিরিক্ত স্পেস বা একটি ট্যাব অক্ষর নীরবে পার্স-ট্রি পাল্টে দেয়। ট্যাব সম্পূর্ণ নিষিদ্ধ — স্পেসিফিকেশন স্পষ্টভাবে ইন্ডেন্টেশনে এগুলো নিষেধ করে, কিন্তু বেশিরভাগ এডিটর দৃশ্যত ট্যাব ও স্পেসের পার্থক্য দেখায় না। সম্পূর্ণ YAML স্পেসিফিকেশনে ৬৩টি কনটেক্সট-সংবেদনশীল ব্যাকরণ নিয়ম আছে, যা একে সঠিকভাবে বাস্তবায়নের সবচেয়ে জটিল ফরম্যাটগুলোর একটি করে তোলে; ভিন্ন পার্সার এজ কেসে ভিন্ন ফলাফল দেয়। ইমপ্লিসিট টাইপ সিস্টেম (নরওয়ে সমস্যা, ডেট পার্সিং, অক্টাল ইন্টিজার লিটারাল) আরও এক স্তর চমক যোগ করে। এই দুর্বলতাগুলোর কারণেই Kustomize, Helm এবং CUE-এর মতো টুল বিদ্যমান — এগুলো কাঁচা Kubernetes YAML-এর ওপর বিমূর্ততা স্তর দেয় কারণ স্কেলে কাঁচা YAML একটি রক্ষণাবেক্ষণ সমস্যা হয়ে দাঁড়ায়।

JSON ডিজাইনে সহজতর: কোনো তাৎপর্যপূর্ণ হোয়াইটস্পেস নেই, কোনো ইমপ্লিসিট টাইপ নেই, একটি ছয়-টোকেন ব্যাকরণ যা এক পৃষ্ঠায় আঁটে এবং সর্বজনীন পার্সার সমর্থন। এর মূল সীমাবদ্ধতা হলো কমেন্টের অনুপস্থিতি এবং প্রতিটি কী উদ্ধৃত করার বাহুল্য। TOML (Tom's Obvious Minimal Language) সরাসরি কনফিগারেশন ফাইলের ব্যবহারকে লক্ষ্য করে: স্পষ্ট টাইপ, কোনো ইন্ডেন্টেশন-সংবেদনশীলতা নেই, কোনো তাৎপর্যপূর্ণ হোয়াইটস্পেস নেই, এবং একটি সিনট্যাক্স যা প্রথাগত INI ফাইলের কাছাকাছি। Rust-এর Cargo.toml, Python-এর pyproject.toml এবং Hugo-র কনফিগ ফাইল TOML ব্যবহার করে কারণ এটি YAML-এর চেয়ে ভুল করা কঠিন এবং কনফিগের জন্য JSON-এর চেয়ে বেশি অভিব্যক্তিময়। সঠিক পছন্দ প্রসঙ্গের ওপর নির্ভর করে: যে DevOps টুলিং ইতিমধ্যে এটি প্রত্যাশা করে তার জন্য YAML; API ও ডেটা বিনিময়ের জন্য JSON; এবং যেসব অ্যাপ্লিকেশন কনফিগ ফাইলে ইকোসিস্টেম গতির চেয়ে কমেন্ট সমর্থন ও স্পষ্ট টাইপ বেশি গুরুত্বপূর্ণ, তার জন্য TOML।

YAML-এর উন্নত বৈশিষ্ট্য — অ্যাংকর, মাল্টিলাইন স্ট্রিং ও মাল্টি-ডকুমেন্ট ফাইল

অ্যাংকর ও অ্যালিয়াস হলো পুনরাবৃত্তি এড়ানোর জন্য YAML-এর অন্তর্নির্মিত ব্যবস্থা। একটি অ্যাংকর যেকোনো নোডে &name দিয়ে সংজ্ঞায়িত হয়, এবং একটি অ্যালিয়াস *name দিয়ে ডকুমেন্টের অন্য যেকোনো জায়গায় সেই নোডের মান পুনরায় ব্যবহার করে। docker-compose.yml-এ একটি সাধারণ প্যাটার্ন হলো একটি শেয়ার করা এনভায়রনমেন্ট ব্লক একবার অ্যাংকর দিয়ে সংজ্ঞায়িত করে একাধিক সার্ভিস ডেফিনিশনে রেফারেন্স করা — প্রতিটি সার্ভিসে একই দশটি এনভায়রনমেন্ট ভেরিয়েবল কপি-পেস্ট করার বদলে। মার্জ কী (<<: *alias) এটিকে আরও প্রসারিত করে: এটি অ্যালিয়াস করা ম্যাপের সব কী-ভ্যালু জোড়া বর্তমান ম্যাপে মার্জ করে, একটি বেস সার্ভিস ডেফিনিশনকে প্রতি-সার্ভিস ওভাররাইড দিয়ে প্রসারিত করতে দেয়। এটি উত্তরাধিকারের সবচেয়ে কাছাকাছি যা YAML পৌঁছায়, এবং মাল্টি-এনভায়রনমেন্ট কনফিগারেশনে ব্যাপকভাবে ব্যবহৃত হয়।

YAML-এ মাল্টিলাইন স্ট্রিং দুটি স্টাইলে আসে যা ভিন্ন উদ্দেশ্য পূরণ করে। লিটারাল ব্লক স্টাইল (|) নিউলাইন যেভাবে লেখা হয়েছে ঠিক সেভাবেই সংরক্ষণ করে — সোর্সের প্রতিটি লাইন ব্রেক পার্স করা স্ট্রিংয়ে একটি লাইন ব্রেক হয়। শেল স্ক্রিপ্ট, SQL কোয়েরি, বা যেকোনো টেক্সট যেখানে লাইন ব্রেক শব্দার্থগতভাবে তাৎপর্যপূর্ণ, তা এম্বেড করার জন্য এটি সঠিক পছন্দ। ফোল্ডেড ব্লক স্টাইল (>) নিউলাইনগুলোকে স্পেসে রূপান্তর করে (ব্লকটিকে একটি প্যারাগ্রাফের মতো বিবেচনা করে), যখন খালি লাইনগুলোকে প্যারাগ্রাফ ব্রেক হিসেবে সংরক্ষণ করে। এটি দীর্ঘ গদ্য মানের জন্য উপযুক্ত — ডকুমেন্টেশন স্ট্রিং, বিবরণ, এরর বার্তা — যেখানে আপনি পড়ার সুবিধার জন্য সোর্সে হার্ড-র‍্যাপ করতে চান কিন্তু কনজিউমারকে একটি একক অখণ্ড স্ট্রিং সরবরাহ করতে চান। উভয় স্টাইলই একটি চম্পিং ইন্ডিকেটর সমর্থন করে: |- চূড়ান্ত নিউলাইন সরিয়ে দেয়, |+ সব ট্রেইলিং নিউলাইন রাখে, এবং খালি | ঠিক একটি নিউলাইন রাখে।

মাল্টি-ডকুমেন্ট YAML একাধিক স্বাধীন YAML ডকুমেন্টকে একটি একক ফাইলে সহাবস্থান করতে দেয়, --- ডকুমেন্ট-স্টার্ট মার্কার দিয়ে আলাদা করা। ঐচ্ছিক ... ডকুমেন্ট-এন্ড মার্কার একটি ডকুমেন্ট স্পষ্টভাবে বন্ধ করে। Kubernetes এই প্যাটার্ন ব্যাপকভাবে ব্যবহার করে — একটি একক manifest.yaml ফাইলে একটি Deployment, একটি Service এবং একটি ConfigMap থাকতে পারে, প্রতিটি --- দিয়ে আলাদা করা, একটি একক kubectl apply -f manifest.yaml দিয়ে একসাথে প্রয়োগ করা। --- সেপারেটর স্ট্রিমিং YAML প্রসঙ্গে একটি সংস্করণ সীমানা হিসেবেও কাজ করে, যেখানে একটি প্রডিউসার একটি সংযোগের ওপর অনির্দিষ্ট ধারার ডকুমেন্ট নির্গত করতে পারে এবং কনজিউমার প্রতিটি আসার সাথে সাথে প্রসেস করে। এই ফরম্যাটার মাল্টি-ডকুমেন্ট ফাইল সমর্থন করে: প্রতিটি ডকুমেন্ট স্বাধীনভাবে পার্স হয়, প্রতি-ডকুমেন্ট ভিত্তিতে এরর রিপোর্ট হয়, এবং JSON রূপান্তর সব ডকুমেন্টকে একটি শীর্ষ-স্তরের অ্যারেতে মুড়ে দেয়।