فصل ۳ — پلتفرم‌های زیرساخت

چشم‌انداز وسیعی از ابزارها وجود دارد که به‌نوعی به زیرساخت ابری مدرن مربوط‌اند. پرسش اینکه کدام فناوری‌ها را انتخاب کنید و چگونه کنار هم بگذارید می‌تواند overwhelming باشد. این فصل مدلی برای فکر کردن دربارهٔ نگرانی‌های سطح‌بالای پلتفرم، قابلیت‌هایی که فراهم می‌کند و منابع زیرساختی که ممکن است برای فراهم کردن آن قابلیت‌ها سرهم کنید ارائه می‌دهد.

این مدل معتبر یا معماری قطعی نیست. راه خودتان را برای توصیف بخش‌های سیستم پیدا خواهید کرد. توافق روی جای درست هر tool یا فناوری در diagram کمتر از داشتن گفت‌وگو اهمیت دارد.

هدف این مدل ایجاد context برای بحث مفاهیم، شیوه‌ها و رویکردهای این کتاب است. نگرانی خاص این است که مطمئن شویم این بحث‌ها صرف‌نظر از technology stack، tool یا platform شما relevant هستند. پس مدل groupingها و terminology تعریف می‌کند که فصل‌های بعدی برای توصیف مثلاً نحوهٔ provision سرور روی پلتفرم virtualization مانند VMware یا IaaS cloud مانند AWS استفاده می‌کنند.

بخش‌های یک سیستم زیرساخت

بخش‌های زیاد و انواع مختلفی در زیرساخت ابری مدرن وجود دارد. گروه‌بندی این بخش‌ها در سه لایهٔ platform برایم مفید است (شکل ۳-۱):

Applications

برنامه‌ها و سرویس‌ها قابلیت‌ها را برای سازمان و کاربرانش فراهم می‌کنند. هر چیز دیگر در این مدل برای enable کردن این لایه وجود دارد.

Application runtimes

application runtimeها سرویس‌ها و قابلیت‌ها را برای لایهٔ application فراهم می‌کنند. نمونه‌های سرویس‌ها و سازه‌ها در پلتفرم application runtime شامل clusterهای container، محیط‌های serverless، application server، سیستم‌عامل و پایگاه داده است. این لایه را Platform as a Service (PaaS) هم می‌نامند.

Infrastructure platform

infrastructure platform مجموعهٔ منابع زیرساخت و toolها و سرویس‌هایی است که آن‌ها را مدیریت می‌کنند. پلتفرم‌های cloud و virtualization منابع زیرساخت از جمله compute، storage و networking primitive فراهم می‌کنند. این را Infrastructure as a Service (IaaS) هم می‌نامند. منابع این لایه را در «Infrastructure Resources» (صفحهٔ ۲۷) گسترش می‌دهم.

شکل ۳-۱. لایه‌های عناصر سیستم

فرض این کتاب استفاده از لایهٔ infrastructure platform برای سرهم کردن منابع زیرساخت و ساخت لایهٔ application runtime است.

فصل ۵ و سایر فصل‌های بخش II توضیح می‌دهند چگونه با کد infrastructure stack بسازید. infrastructure stack مجموعه‌ای از منابع است که با ابزاری مانند Ansible، CloudFormation، Pulumi یا Terraform با هم تعریف و مدیریت می‌شود.

فصل ۱۰ و سایر فصل‌های بخش III توضیح می‌دهند چگونه با کد application runtime تعریف و مدیریت کنید. این‌ها شامل server، cluster و محیط‌های اجرای serverless هستند.

پلتفرم‌های زیرساخت

زیرساخت به‌عنوان کد به پلتفرم زیرساخت پویا نیاز دارد؛ چیزی که بتوانید با API on demand منابع provision و تغییر دهید. شکل ۳-۲ لایهٔ infrastructure platform را در مدل platform highlight می‌کند. این تعریف essential ابر است.[^1] وقتی در این کتاب از «infrastructure platform» صحبت می‌کنم، می‌توانید فرض کنید منظور پلتفرم dynamic از نوع IaaS است.[^2]

شکل ۳-۲. infrastructure platform لایهٔ foundation مدل platform است

در روزهای قدیم — عصر آهن محاسبات — زیرساخت سخت‌افزار بود. virtualization سیستم‌ها را از سخت‌افازی که روی آن اجرا می‌شدند decouple کرد و cloud API برای مدیریت آن منابع مجازی‌شده اضافه کرد.[^3] عصر ابری آغاز شد.

انواع مختلف پلتفرم زیرساخت وجود دارد، از public cloud کامل تا private cloud؛ از vendorهای commercial تا پلتفرم‌های open source. در این فصل این variationها را outline می‌کنم و سپس انواع مختلف منابع زیرساخت را که فراهم می‌کنند توصیف می‌کنم. جدول ۳-۱ نمونه‌های vendor، product و tool برای هر نوع پلتفرم زیرساخت cloud را فهرست می‌کند.

نوع پلتفرم	ارائه‌دهندگان یا محصولات
Public IaaS cloud services	AWS، Azure، Digital Ocean، GCE، Linode، Oracle Cloud، OVH، Scaleway و Vultr
Private IaaS cloud products	CloudStack، OpenStack و VMware vCloud
Bare-metal cloud tools	Cobbler، FAI و Foreman

در سطح پایه، پلتفرم‌های زیرساخت منابع compute، storage و networking فراهم می‌کنند. پلتفرم‌ها این منابع را در formatهای مختلف ارائه می‌دهند. مثلاً ممکن است compute را به‌صورت virtual server، container runtime و اجرای کد serverless اجرا کنید.

PaaS

بیشتر cloud vendorهای public منابع یا bundle منابعی ارائه می‌دهند که برای deploy و manage برنامه‌ها سرویس‌های سطح‌بالاتر می‌سازند. نمونه‌های سرویس PaaS hosted شامل Heroku، AWS Elastic BeanStalk و Azure Devops است.[^4]

vendorهای مختلف ممکن است همان منابع را به‌شکل یا حداقل با نام‌های مختلف package و offer کنند. مثلاً AWS object storage، Azure blob storage و GCP cloud storage تقریباً یک چیزند. این کتاب تمایل دارد از نام‌های generic استفاده کند که روی پلتفرم‌های مختلف اعمال می‌شوند. به‌جای VPC و Subnet، از network address block و VLAN استفاده می‌کنم.

Multicloud

بسیاری از سازمان‌ها در نهایت روی چند پلتفرم host می‌کنند. چند اصطلاح برای variationهای این کار ظاهر می‌شود:

Hybrid cloud

host کردن برنامه‌ها و سرویس‌های یک سیستم هم روی زیرساخت private و هم سرویس public cloud. مردم اغلب به‌دلیل legacy systemهایی که نمی‌توانند به‌راحتی به public cloud migrate کنند (مثل سرویس‌های روی mainframe) این کار را می‌کنند. در موارد دیگر، سازمان requirementهایی دارند که public cloud vendor فعلاً برآورده نمی‌کند، مانند الزامات قانونی host کردن data در کشوری که vendor حضور ندارد.

Cloud agnostic

ساخت سیستم‌ها طوری که روی چند public cloud platform اجرا شوند. مردم اغلب امید lock-in به یک vendor را avoid کنند. در عمل، این به lock-in به نرم‌افزاری که وعدهٔ پنهان کردن تفاوت‌های cloud را می‌دهد، یا ساخت و نگه‌داری حجم عظیمی کد سفارشی، یا هر دو منجر می‌شود.

Polycloud

اجرای برنامه‌ها، سرویس‌ها و سیستم‌های مختلف روی بیش از یک public cloud platform. معمولاً برای بهره‌برداری از نقاط قوت پلتفرم‌های مختلف است.

منابع زیرساخت

سه منبع essential که پلتفرم زیرساخت فراهم می‌کند: compute، storage و networking. پلتفرم‌های مختلف این منابع را به‌شکل‌های مختلف combine و package می‌کنند. مثلاً ممکن است بتوانید virtual machine و container instance provision کنید. شاید بتوانید database instance provision کنید که compute، storage و networking را combine می‌کند.

منابع زیرساخت elemental‌تر را primitive می‌نامم. هر کدام از منابع compute، networking و storage که در بخش‌های بعد توصیف می‌شوند primitive است. پلتفرم‌های cloud primitiveهای زیرساخت را در composite resourceها combine می‌کنند، مانند:

• Database as a Service (DBaaS)
• Load balancing
• DNS
• Identity management
• Secrets management

خط بین primitive و composite resource arbitrary است، همان‌طور که خط بین composite infrastructure resource و سرویس application runtime. حتی یک سرویس storage پایه مانند object storage (مثل AWS S3 bucket) برای read و write data به compute و networking نیاز دارد. اما تمایز مفید است که اکنون برای فهرست formatهای رایج primitiveهای زیرساخت استفاده می‌کنم. این‌ها زیر سه نوع منبع پایه قرار می‌گیرند: compute، storage و networking.

منابع Compute

منابع compute کد را اجرا می‌کنند. در elemental‌ترین حالت، compute زمان اجرا روی core فیزیکی CPU سرور است. اما پلتفرم‌ها compute را به‌شکل‌های مفیدتر فراهم می‌کنند.

منابع compute رایج شامل:

Virtual machines (VMs)

پلتفرم زیرساخت poolی از host server فیزیکی را manage می‌کند و instanceهای virtual machine را روی hypervisor در این hostها اجرا می‌کند. فصل ۱۱ جزئیات بیشتری دربارهٔ provision، پیکربندی و manage سرورها می‌دهد.

Physical servers

که bare metal هم نامیده می‌شود، پلتفرم به‌صورت dynamic سرور فیزیکی on demand provision می‌کند. «Using a Networked Provisioning Tool to Build a Server» (صفحهٔ ۱۸۲) mechanism خودکار provision سرور فیزیکی به‌عنوان bare-metal cloud را توصیف می‌کند.

Server clusters

server cluster poolی از instance سرور — virtual machine یا physical server — است که پلتفرم زیرساخت به‌عنوان گروه provision و manage می‌کند. نمونه‌ها شامل AWS Auto Scaling Group (ASG)، Azure virtual machine scale set و Google Managed Instance Groups (MIGs) است.

Containers

بیشتر پلتفرم‌های cloud Containers as a Service (CaaS) برای deploy و اجرای container instance ارائه می‌دهند. اغلب container image را در format استاندارد (مثلاً Docker) می‌سازید و پلتفرم از آن برای اجرای instance استفاده می‌کند. بسیاری از پلتفرم‌های application runtime حول containerization ساخته شده‌اند. فصل ۱۰ بیشتر بحث می‌کند. container به host server برای اجرا نیاز دارد. برخی پلتفرم‌ها این hostها را transparent فراهم می‌کنند، اما بسیاری باید cluster و hostهایش را خودتان تعریف کنید.

Application hosting clusters

application hosting cluster poolی از server است که پلتفرم چند برنامه را روی آن deploy و manage می‌کند.[^5]

نمونه‌ها شامل Amazon Elastic Container Services (ECS)، Amazon Elastic Container Service for Kubernetes (EKS)، Azure Kubernetes Service (AKS) و Google Kubernetes Engine (GKE) است. می‌توانید package application hosting را روی پلتفرم زیرساخت deploy و manage کنید. «Application Cluster Solutions» (صفحهٔ ۲۳۰) را ببینید.

FaaS serverless code runtimes

پلتفرم زیرساخت کد serverless Function as a Service (FaaS) را on demand، در پاسخ به event یا schedule اجرا می‌کند و پس از اتمام action آن را terminate می‌کند. «Infrastructure for FaaS Serverless» (صفحهٔ ۲۴۶) را ببینید. offeringهای serverless پلتفرم زیرساخت شامل AWS Lambda، Azure Functions و Google Cloud Functions است.

Serverless فراتر از کد

مفهوم serverless فراتر از اجرای کد می‌رود. Amazon DynamoDB و Azure Cosmos DB پایگاه دادهٔ serverless هستند: سرورهای درگیر host پایگاه داده برای شما transparent هستند، برخلاف offeringهای DBaaS سنتی‌تر مانند AWS RDS.

برخی پلتفرم‌های cloud محیط‌های اجرای برنامهٔ تخصصی on-demand ارائه می‌دهند. مثلاً می‌توانید AWS SageMaker، Azure ML Services یا Google ML Engine را برای deploy و اجرای مدل machine learning استفاده کنید.

منابع Storage

سیستم‌های پویا زیاد به storage نیاز دارند، مانند disk volume، پایگاه داده یا repository مرکزی فایل. حتی اگر برنامه مستقیماً storage استفاده نکند، بسیاری از سرویس‌هایی که استفاده می‌کند به آن نیاز دارند، حداقل برای ذخیرهٔ compute image (مثل snapshot virtual machine و container image).

پلتفرم genuinely dynamic storage را برای برنامه‌ها transparent manage و فراهم می‌کند. این feature با سیستم‌های virtualization کلاسیک متفاوت است، جایی که باید صریحاً مشخص کنید کدام storage فیزیکی به هر instance compute allocate و attach شود.

منابع storage معمول روی پلتفرم‌های زیرساخت:

Block storage (virtual disk volumes)

می‌توانید volume block storage را به یک server یا container instance attach کنید گویی disk محلی است. نمونه‌های سرویس block storage که cloud platform فراهم می‌کند شامل AWS EBS، Azure Page Blobs، OpenStack Cinder و GCE Persistent Disk است.

Object storage

می‌توانید object storage را برای ذخیره و دسترسی فایل از چند مکان استفاده کنید. Amazon S3، Azure Block Blobs، Google Cloud Storage و OpenStack Swift همه نمونه‌اند. object storage معمولاً ارزان‌تر و reliable‌تر از block storage است، اما latency بالاتر دارد.

Networked filesystems (shared network volumes)

بسیاری از پلتفرم‌های cloud volume storage مشترک فراهم می‌کنند که با protocolهای استاندارد مانند NFS، AFS و SMB/CIFS[^6] روی چند instance compute mount می‌شوند.

Structured data storage

بیشتر پلتفرم‌های زیرساخت Database as a Service (DBaaS) managed فراهم می‌کنند که می‌توانید به‌صورت کد تعریف و manage کنید. ممکن است برنامهٔ پایگاه دادهٔ commercial یا open source استاندارد مانند MySQL، Postgres یا SQL Server باشد. یا سرویس storage دادهٔ ساختاریافتهٔ سفارشی؛ مثلاً key-value store یا formatted document store برای محتوای JSON یا XML. vendorهای major cloud سرویس storage و پردازش data برای manage، transform و analyze حجم زیاد data هم ارائه می‌دهند. این‌ها شامل سرویس batch data processing، map-reduce، streaming، indexing و searching و موارد دیگر است.

Secrets management

هر منبع storage می‌تواند encrypt شود تا password، key و اطلاعات دیگری که attacker ممکن است برای دسترسی privileged به سیستم‌ها و منابع exploit کند ذخیره کنید. سرویس secrets management functionalityی اضافه می‌کند که specifically برای manage این نوع منابع طراحی شده. «Handling Secrets as Parameters» (صفحهٔ ۱۰۲) را برای techniqueهای manage secret و کد زیرساخت ببینید.

منابع Network

همان‌طور که با سایر انواع منابع زیرساخت، توانایی پلتفرم‌های پویا برای provision و تغییر networking on demand از کد، فرصت‌های بزرگی ایجاد می‌کند. این فرصت‌ها فراتر از تغییر سریع‌تر networking است؛ شامل استفادهٔ بسیار ایمن‌تر از networking هم می‌شود.

بخشی از ایمنی از توانایی test سریع و دقیق تغییر پیکربندی networking قبل از apply روی محیط critical می‌آید. فراتر از این، Software Defined Networking (SDN) امکان ساخت constructهای امنیت شبکهٔ fine-grained‌تر از کاری که دستی می‌توانید انجام دهید را می‌دهد. این به‌ویژه با سیستم‌هایی که elementها را dynamically می‌سازید و destroy می‌کنید صادق است.

مدل امنیت Zero-Trust با SDN

مدل امنیت zero-trust هر سرویس، برنامه و منبع دیگر در سیستم را در پایین‌ترین سطح secure می‌کند.[^7] این با مدل امنیت perimeter-based سنتی متفاوت است که فرض می‌کند هر device داخل شبکهٔ secure قابل اعتماد است.

پیاده‌سازی مدل zero-trust برای سیستم nontrivial فقط با تعریف سیستم به‌صورت کد feasible است. کار دستی manage control برای هر process در سیستم در غیر این صورت overwhelming می‌شود.

برای سیستم zero-trust، هر برنامهٔ جدید annotate می‌شود تا نشان دهد به کدام برنامه‌ها و سرویس‌ها نیاز دسترسی دارد. پلتفرم از این برای enable خودکار دسترسی لازم و block همهٔ چیز دیگر استفاده می‌کند.

مزایای این رویکرد شامل:

• هر برنامه و سرویس فقط privilege و دسترسی‌ای دارد که صریحاً نیاز دارد؛ این principle of least privilege را دنبال می‌کند.
• امنیت zero-trust یا perimeterless شامل گذاشتن barrier و control با scope کوچک‌تر روی منابع specificی است که باید protect شوند. این نیاز به trust zone با scope broad — مثلاً grant trust به هر device متصل به شبکهٔ فیزیکی — را avoid می‌کند.
• روابط امنیتی بین elementهای سیستم visible است که validation، auditing و reporting را enable می‌کند.

constructها و سرویس‌های networking معمول که پلتفرم زیرساخت فراهم می‌کند شامل:

Network address blocks

network address block ساختار fundamental برای group کردن منابع و control routing ترافیک بین آن‌هاست. block سطح‌بالا در AWS VPC (Virtual Private Cloud) است. در Azure، GCP و دیگران Virtual Network است. block سطح‌بالا اغلب به blockهای کوچک‌تر تقسیم می‌شود، مانند subnet یا VLAN. ساختار networking خاصی مانند AWS subnet ممکن است با مکان فیزیکی مانند data center مرتبط باشد که برای manage availability استفاده می‌کنید.

Names، مانند DNS entries

nameها به address شبکهٔ سطح پایین‌تر — معمولاً IP address — map می‌شوند.

Routes

پیکربندی کنید چه ترافیکی بین و درون address block مجاز است.

Gateways

ممکن است برای direct کردن ترافیک داخل و خارج block لازم باشند.

Load balancing rules

connectionهای ورودی به یک address را به pool منابع forward کنید.

Proxies

connection را accept کنند و با rule آن‌ها را transform یا route کنند.

API gateways

proxy، معمولاً برای connection HTTP/S، که فعالیت‌هایی برای handle جنبه‌های noncore API مانند authentication و rate throttling انجام می‌دهد. «Service Mesh» (صفحهٔ ۲۴۴) را هم ببینید.

VPNs (virtual private networks)

address blockهای مختلف را در locationهای مختلف connect کنید تا بخشی از یک شبکه به نظر برسند.

Direct connection

connection اختصاصی بین شبکهٔ cloud و location دیگر، معمولاً data center یا office network.

Network access rules (firewall rules)

ruleهایی که ترافیک بین locationهای شبکه را restrict یا allow می‌کنند.

Asynchronous messaging

queue برای send و receive message بین processها.

Cache

cache data را در locationهای شبکه distribute می‌کند تا latency بهبود یابد. CDN (Content Distribute Network) سرویسی است که content static (و در برخی موارد executable code) را به چند location جغرافیایی distribute می‌کند، معمولاً برای content تحویل‌شده با HTTP/S.

Service mesh

شبکهٔ decentralized سرویس‌ها که connectivity بین بخش‌های سیستم distributed را dynamically manage می‌کند. قابلیت‌های networking را از لایهٔ infrastructure به لایهٔ application runtime مدلی که در «The Parts of an Infrastructure System» (صفحهٔ ۲۳) توصیف کردم منتقل می‌کند.

جزئیات networking خارج از scope این کتاب است، پس documentation platform provider و شاید مرجعی مانند TCP/IP Network Adminstration Craig Hunt (O'Reilly) را ببینید.

جمع‌بندی

انواع مختلف منابع و سرویس‌های زیرساخت که در این فصل پوشش داده شد، قطعاتی هستند که در سیستم‌های مفید می‌چینید — بخش «infrastructure» در Infrastructure as Code.

[^1]: US National Institute of Standards and Technology (NIST) تعریف عالی cloud computing دارد.

[^2]: NIST IaaS را این‌طور تعریف می‌کند: «قابلیتی که به consumer داده می‌شود provision کردن processing، storage، network و سایر منابع محاسباتی fundamental است، جایی که consumer می‌تواند نرم‌افزار arbitrary — از جمله سیستم‌عامل و برنامه‌ها — deploy و اجرا کند. consumer زیرساخت cloud زیرین را manage یا control نمی‌کند اما control روی سیستم‌عامل، storage و برنامه‌های deployed دارد؛ و شاید control محدود روی componentهای networking انتخابی (مثلاً host firewall).»

[^3]: فناوری virtualization از دههٔ ۱۹۶۰ وجود داشته، اما در دههٔ ۲۰۰۰ به دنیای mainstream سرورهای x86 وارد شد.

[^4]: نمی‌توانم Azure DevOps را بدون اشاره به terribleness آن نام برای یک سرویس ذکر کنم. DevOps اول culture است، نه tool و فناوری. review Matt Skelton از سخنرانی John Willis دربارهٔ فرهنگ DevOps را بخوانید.

[^5]: application hosting cluster را با PaaS اشتباه نگیرید. این نوع cluster provision منابع compute برای برنامه‌ها را manage می‌کند که یکی از core functionهای PaaS است. اما PaaS کامل variety سرویس‌هایی فراتر از compute فراهم می‌کند.

[^6]: به‌ترتیب Network File System، Andrew File System و Server Message Block.

[^7]: Google رویکرد zero-trust (که perimeterless هم نامیده می‌شود) را با مدل امنیت BeyondCorp document می‌کند.