├── .gitignore ├── README.md ├── config.toml ├── content └── blog │ ├── container-design-patterns-full.md │ ├── docker-basic-concepts.md │ ├── docker-compose-intro-part1.md │ ├── docker-faq.md │ ├── how-to-run-official-images.md │ ├── how-to-write-dockerfile.md │ ├── install-docker-centos7.md │ ├── install-docker-on-ubuntu-16.04.md │ ├── install-docker-windows.md │ ├── java-springboot-docker.md │ ├── jboss-docker-tutorial.md │ ├── kubernetes-expose-traffic.md │ ├── use-gosu-not-sudo.md │ ├── useful-docker-commands.md │ ├── what-is-kubernetes-why-need-it.md │ ├── what-is-registry-repository.md │ └── why-you-need-docker.md ├── layouts ├── 404.html ├── _default │ ├── li.html │ ├── list.html │ └── single.html ├── index.html └── partials │ ├── footer.html │ ├── header.html │ └── pagination.html ├── scripts ├── deploy_to_s3.sh └── run_local.sh ├── static ├── css │ ├── font-awesome.min.css │ └── style.css ├── fonts │ ├── IRSansWeb.eot │ ├── IRSansWeb.ttf │ ├── IRSansWeb.woff │ └── IRSansWeb.woff2 ├── img │ ├── apple-touch-icon.jpg │ ├── avatar.jpg │ ├── cross.png │ ├── favicon.ico │ ├── logo.png │ ├── plane.jpg │ ├── screenshot.png │ └── texture.png └── js │ └── highlight.pack.js └── themes └── allegiant ├── README.md ├── archetypes └── default.md ├── config.toml ├── content └── post │ ├── features.md │ └── introducing-allegiant-a-hugo-theme.md ├── images ├── screenshot.png └── tn.png ├── layouts ├── 404.html ├── _default │ ├── li.html │ ├── list.html │ └── single.html ├── index.html └── partials │ ├── footer.html │ ├── header.html │ └── pagination.html ├── static ├── css │ ├── font-awesome.min.css │ └── style.css ├── fonts │ ├── FontAwesome.otf │ ├── IRSansWeb.eot │ ├── IRSansWeb.ttf │ ├── IRSansWeb.woff │ ├── IRSansWeb.woff2 │ ├── fontawesome-webfont.eot │ ├── fontawesome-webfont.svg │ ├── fontawesome-webfont.ttf │ ├── fontawesome-webfont.woff │ └── fontawesome-webfont.woff2 ├── img │ ├── apple-touch-icon.jpg │ ├── avatar.jpg │ ├── cross.png │ ├── favicon.ico │ ├── plane.jpg │ ├── screenshot.png │ └── texture.png └── js │ └── highlight.pack.js └── theme.toml /.gitignore: -------------------------------------------------------------------------------- 1 | /public 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Elastico.io Blog 2 | 3 | This repo contains all the blog posts on elastico.io in Markdown format. 4 | 5 | Feel free to fork and contribute a new post by sending a pull request. 6 | -------------------------------------------------------------------------------- /config.toml: -------------------------------------------------------------------------------- 1 | baseurl = "http://elastico.io" 2 | languageCode = "fa-ir" 3 | title = "الستیکو" 4 | copyright = "© کلیه حقوق محفوظ است. بازنشر این مطلب تنها با ذکر آدرس کامل این سایت مجاز است" # Copyright notice. This will be displayed in the footer. 5 | canonifyurls = true 6 | uglyurls = true 7 | 8 | [params] 9 | ga_api_key = "UA-73618104-1" # Google Analytics API key. 10 | avatar = "../../img/avatar.jpg" # Image should be square, and roughly 150px x 150px 11 | #bio = "Insert your bio here." 12 | github = "https://github.com/etcinitd/elastico-io-blog" 13 | #twitter = "https://twitter.com/username" 14 | linkedin = "http://www.linkedin.com/groups/7019646" 15 | telegram = "https://telegram.me/joinchat/DBSHvj6Jmd0FYWfhyvrnvw" 16 | #footer_1 = "Some text here." 17 | #footer_2 = "Some different text here." 18 | #footer_3 = "Even more different text here." 19 | -------------------------------------------------------------------------------- /content/blog/container-design-patterns-full.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-23T14:55:02+04:30" 3 | draft = false 4 | title = "الگوهای طراحی در سیستمهای توزیع شده مبتنی بر کانتینر" 5 | 6 | +++ 7 | 8 | الگوهای طراحی در سیستمهای توزیع شده مبتنی بر کانتینر 9 | === 10 | این نوشتار ترجمه ای از [مقاله ای با همین عنوان است از مهندسین شرکت گوگل](https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf) که توسط آقای بابک قدیری ترجمه شده است. 11 | 12 | مقدمه 13 | --- 14 | در اواخر دهه ۸۰ و اوایل دهه ۹۰، برنامه‌نویسی شی‌گرا، توسعه نرم افزار را به کلی متحول کرد و باعث فراگیر شدن رویکرد ساخت برنامه ها به شکل مجموعه ای از مولفه های مستقل از هم شد. امروزه با گسترش محبوبیت و فراگیر شدن معماری ریزسرویسهایی که توسط محفظه‌هایی از قطعات نرم‌افزاری ساخته شده‌اند، شاهد انقلابی مشابه در توسعه سیستمهای توزیع‌شده هستیم. 15 | 16 | محفظه ها را با توجه به مرز روشنی که با بقیه سیستم دارند، میتوان به عنوان "اشیا" ی پایه در سیستمهای توزیع شده در نظر گرفت. همزمان با اینکه این سبک معماری بالغتر میشود، ما شاهد ظهور الگوهای طراحی برای آن هستیم همان اتفاقی که در برنامه های شی گرا افتاد. به دلیلی مشابه که فکر کردن به اشیا (یا محفظه‌ها) با انتزاع از جزئیات سطح پایین کدها بود که در ادامه به پیدایش الگوهای سطح بالاتر انجامید که در کاربردها و الگوریتمهای مختلفی رایج هستند. 17 | 18 | در این مقاله سه نوع از الگوهای طراحی که در محیط های توزیع شدهٔ محفظه-مبنا مشاهده کرده ایم را توصیف میکنیم: 19 | 20 | * الگوهای تک محفظه‌ای برای مدیریت محفظه‌ها 21 | * الگوهای تک-گره‌ای برای محفظه‌های همکار و شدیدا وابسته به هم 22 | * الگوهای چند-گره‌ای برای الگوریتمهای توزیع شده. 23 | 24 | این الگوها برای محاسبات توزیع شده، همانند نظایرشان در شی‌گرایی، شامل رویه های برتر هستند. روند توسعه را ساده میکنند و سیستمهایی که در آنها مورد استفاده قرار گیرند را قابل اتکاتر میکنند. 25 | 26 | 27 | الگوهای طراحی سیستمهای توزیع‌شده 28 | --- 29 | پس از سالها استفاده از برنامه نویسی شی‌گرا، الگوهای طراحی ظهور کردند و مستند شدند. این الگوها برخی از مسائل و مشکلات رایج در برنامه نویسی را طبقه‌بندی و مشخص کردند و رویکردهای کلی برای حل آنها ارائه دادند. الگوها همچنین باعث پیشرفت لبه تکنولوژی توسعه در برنامه نویسی شدند. چون به برنامه نویسان کم تجربه تر امکان نوشتن کدهای بهتر و خوش ساخت‌تر را میدادند و توسعه کتابخانه های قابل استفاده مجدد را ممکن میکردند که با استفاده از آنهای کدهای قابل اتکاتر، سریعتر تولید می‌شدند. 30 | 31 | امروزه وضعیت مهندسی سیستمهای توزیع شده بسیار مشابه شرایط برنامه نویسی در اویل دهه ۸۰ است بیش از آنکه شبیه توسعه شی گرا باشد. 32 | 33 | با توجه به موفقیت الگوی MapReduce در به ارمغان آوردن قدرت برنامه نویسی کلان داده برای مجموعه گسترده ای از زیرشاخه ها و برنامه نویسان، بسیار روشن است که استفاده به جا از مجموعه الگوها میتواند به شکل چشمگیری کیفیت، سرعت و سهولت استفاده از سیستمهای توزیع شده را بهبود دهد. اما حتی موفقیت MapReduce بسیار محدود به یک زبان برنامه نویسی است تا جاییکه اکوسیستم Apache Hadoop غالبا با جاوا و برای جاوا نوشته شده است. 34 | 35 | توسعه‌ی یک مجموعه فراگیر از الگوها برای طراحی سیستمهای توزیع شده نیاز به یک زبان مشترک عام منظوره برای نمایش اجزای سیستم دارد. 36 | 37 | خوشبختانه دو سال اخیر مقبولیت چشمگیری را در تکنولوژی محفظه های لینوکسی شاهد بودیم. محفظه و تصویر محفظه دقیقا همان انتزاعهایی هستند که در ساخت الگوهای سیستمهای توزیع شده نیاز بود. تا امروز محفظه ها و تصاویر محفظه ها قسمت اعظم مقبولیت خود را به واسطه اینکه یک روش بهتر و قابل اتکاتر در تحویل محصول از مرحله توسعه به مرحله استقرار بودند، بدست آوردند. با داشتن این خاصیت که کاملا سربسته و خوداتکا هستند و تمام نیازمندیهایشان همراه خودشان هست و یک نشانه استقرار اتمیک میدهند (موفقیت کامل یا شکست)، به شکل چشمگیری لبه تکنولوژی در استقرار نرم افزارها در مراکز داده و فضای ابری را بهبود بخشیده اند. اما محفظه‌ها پتانسیل آن را دارند که چیزی فراتر از تنها یک ابزار بهتر برای استقرار باشند. ما معتقدیم که تقدیر آنها این است که معادل اشیا در سیستمهای شی گرا باشند و بوسیله آنها امکان توسعه الگوهای سیستمهای توزیع‌شده فراهم آید. 38 | 39 | در ادامه توضیح می‌دهیم که چرا به این موضوع معتقدیم و بعضی از الگوهایی که شاهد ظهورشان بوده‌ایم را برای شکل دادن و هدایت مهندسی سیستمهای توزیع‌شده در سالهای آینده توضیح می‌دهیم. 40 | 41 | الگوهای مدیریت تک-محفظه‌ای 42 | --- 43 | محفظه یک مرز مشخص برای تعریف یک واسط خیلی شبیه مرز یک شی ارائه می‌دهد. محفظه ها از طریق این واسط می‌توانند نه تنها کاربردهای خاص برنامه را ارائه دهند، بلکه می‌توانند قلابهایی را در اختیار سیستمهای مدیریتی قرار دهند. واسطهای سنتی برای مدیریت محفظه بسیار محدود هستند. یک محفظه فقط می‌تواند واسط استفاده از سه دستورالعمل runو pauseوstop را به بیرون دهد. 44 | 45 | گرچه این واسط مفید است، یک واسط غنی تر می‌تواند منفعت بیشتری به توسعه‌دهندگان و اپراتورها بدهد. با پشتیبانی از وب سرورهای HTTP در تقریبا تمام زبانهای مدرن برنامه نویسی و پشتیبانی وسیع برای فرمت داده‌هایی شبیه json ، بسیار ساده خواهد بود که یک api مدیریتی بر مبنای http داشته باشیم. این واسط می‌تواند با داشتن محفظه ای که به اضافه کارکردهای اصلی خود، یک وب سرور درونی هم داشته باشد، پیاده سازی شود. 46 | 47 | "در جهت رو به بیرون" محفظه می‌تواند یک مجموعه غنی از اطلاعات برنامه کاربردی شامل معیارهای مانیتورینگ مختص کاربرد (مثل QPS و معیارهای سلامت برنامه ) اطلاعات profiling مورد توجه برنامه نویسان (شامل اطلاعات ریسه‌ها، پشته، رقابت روی قفل)اطلاعات پیکربندی مولفه‌ها و لاگهای مولفه‌ها را یبرون بدهد. به عنوان یک مثال عینی Kubernetes و Aurora و Marathon و بقیه سیستمهای مدیریت محفظه، اجازه می‌دهند که کاربران تست های سلامتی خاصی را با urlهای خاصی تعریف کنند.(/health) پشتیبانی استاندارد از بقیه مواردی که نام بردیم بسیار نادرتر است. 48 | 49 | "در جهت رو به پایین" واسط محفظه، یک جای طبیعی برای تعریف یک سازوکاری است که نوشتن مولفه‌های نرم افزاری، که توسط یک سیستم مدیریت کنترل میشوند، را آسانتر می‌کند.برای مثال یک سیستم مدیریت خوشه‌ها معمولا به "وظایف"، اولویت های مختلف می‌دهد. وظایف با اولویت بالاتر باید حتی در صورتی که خوشه فوق اشباع باشد هم اجرایشان تضمین شده باشد. این تضمین با خارج کردن وظایف کم اهمیت تر در حال اجرا انجام می‌شود که باید منتظر بمانند که دوباره منابع در اختیارشان قرار بگیرد. این خارج کردن می‌تواند به سادگی با کشتن وظیفه کم اهمیت پیاده سازی شود اما در اینصورت برنامه نویس مجبور به تحمل این مشقت می‌شود که به هر مرگ احتمالی در هر قسمت از کد واکنش نشان دهد تا داده ها و محاسبات در حالت ناسازگاری باقی نماند. 50 | 51 | اگر در عوض یک سازوکار صوری و مشخص بین برنامه و سیستم مدیریت، تعریف شود، مولفه‌های برنامه قابل مدیریت تر می‌شوند چون می‌توانند خودشان را نسبت به یک قرارداد تعریف شده وفق بدهند و توسعه سیستمها آسانتر می‌شود چون برنامه نویس می‌تواند روی قرارداد حساب کند. برای مثال Kubernetes از یک ویژگی با نام حذف مطبوع در داکر استفاده می‌کند که به محفظه با سیگنال SIGTERM اطلاع می‌دهد که باید پایان یابد. بعد از مدت زمانی قابل تعیین سیگنال SIGKILL برایش فرستاده می‌شود. این روند به برنامه امکان می‌دهد که با اتمام اعمال نیمه کاره، نوشتن حالتدر دیسک و غیره به شکل مناسبی پایان یابد. 52 | 53 | قابل تصور است که از این روش برای پشتیبانی از متوالی سازی حالات و بازیابی آنها استفاده کرد. که مدیریت حالت ها را برای سیستمهای توزیع شدهٔ حالتمند بسیار ساده تر می‌کند. به عنوان یک مثال عینی از یک سازوکار پیچیده تر، مدل فعالیت در اندروید را در نظر بگیرید که یک سری نقاط فراخوانی (مثل oncreate ،onstart ،onstop ,...) را ارائه می‌دهد و به شکل صوری یک ماشین حالت را توصیف می‌کند که سیستم چگونه آنها را برمی‌انگیزد. بدون این سازوکار صوری ساخت برنامه های قابل اتکا و مقاوم بسیار سختتر می‌شد. 54 | 55 | در بافتار سیستمهای محفظه-مبنا این مفهوم به قلابهای تعریف شده تعمیم می‌یابد که در زمانهای خاصی (مثلا زمانیکه یک محفظه ساخته می‌شود یا شروع می‌شود و یا قبل از اتمامش و غیره) توسط سیستم مدیریت محفظه فراخوانی می‌شود و برنامه می‌تواند عملکرد خاص خودش را برای فراخوانده شدن هرکدام از این قلابها، تعریف کند. مثال دیگری از “جهت رو به پایین” این است که یک محفظه ممکن است از عملیات خود-شبیه‌سازی پشتیبانی کند (برای گسترش پذیری عمودی سرویس). 56 | 57 | الگوهای چند محفظه روی تک-گره 58 | --- 59 | فراتر از واسط یک محفظه، ما چند الگو طراحی را مشاهده می‌کنیم که با چندین محفظه سروکار دارند. ما قبلا در اینجا چند نمونه از این الگوها را نام برده‌ایم. این الگوهای تک گره‌ای شامل چند محفظه شدیدا به هم وابسته هستند که روی یک ماشین میزبان اجرا میشوند. پشتیبانی سیستمهای مدیریت محفظه از زمانبندی چندین محفظه به شکل یک واحد مجزا، مثل انتزاع Kubernetes که “PODS” و انتزاع Nomad که "گروههای کاری" نامیده می‌شود، یک ویژگی لازم است برای اینکه ما بتوانیم الگوهایی که در این بخش، معرفی کرده‌ایم را به کار بگیریم. 60 | 61 | الگویSidecar 62 | --- 63 | اولین و شایعترین الگو برای استقرارهای چند محفظه ای الگوی Sidecar است. محفظه های Sidecar عملکرد محفظه اصلی را گسترش یا بهبود می‌دهند. برای مثال محفظه اصلی ممکن است یک کارگزار وب باشد. این محفظه می‌تواند با یک محفظه Sidecar ذخیره لاگ جفت شود که لاگهای کارگزار را از دیسک جمع آوری می‌کند و آنها را به شکل جریانی از اطلاعات به سیستم مرکزی ذخیره سازی لاگ می‌فرستد. شکل زیر نمونه‌ای از الگوی Sidecar را نشان می‌دهد. 64 | 65 | مثال شایع دیگر یک محفظه اصلی کارگزار وب است که محتوایی را از روی دیسک محلی می‌خواند و نمایش می‌دهد. این محتوا توسط یک محفظه Sidecar به صورت دوره ای از مخزن گیت یا سیستم مدیریت محتوا یا هر منبع دیگری از داده، گرد آوری می‌شود. هردوی این مثالها در گوگل به وفور استفاده می‌شوند. 66 | 67 | دلیل امکان وجود محفظه های Sidecar این است که محفظه های روی یک ماشین می‌توانند قسمتی از دیسک محلی را با هم به اشتراک بگذارند.با وجود اینکه همیشه ممکن است کارکرد محفظهSidecar را از ابتدا در محفظه اصلی داشته باشیم، از جدا کردن این دو محفظه فواید زیر حاصل می‌شود. 68 | 69 | اول اینکه محفظه، واحد اختصاص و حسابرسی منابع است بنابراین برای مثال محفظه‌ی کارگزار وب می‌تواند به شکلی تنظیم شود که تاخیر ثابت و کمی در پاسخ به پرس‌وجو ها داشته باشد در حالیکه محفظه‌ی ذخیره سازی لاگ می‌تواند به شکلی پیکربندی شود که تنها در صورت بیکار بودن CPU و در زمانی که سر کارگزار وب شلوغ نیست، کارش را انجام دهد. 70 | 71 | دوم اینکه محفظه واحد بسته بندیاست. بنابراین جداسازی نمایش فایلها و ذخیره لاگها به محفظه هایی مختلف، باعث ساده تر شدن تقسیم وظایف توسعه هر کدام بین دو تیم مختلف برنامه نویسی می‌شود و این امکان داده می‌شود که هر کدام جداگانه تست شود. 72 | 73 | سوم اینکه محفظه واحد استفاده مجدد است. بنابراین محفظه های Sidecar می‌توانند به تعدادی محفظه‌ی اصلی با تنوعی مختلف متصل شوند.برای مثلا یک محفظه ذخیره سازی لاگ می‌تواند در کنار هر مولفه ای که لاگ تولید می‌کند، استفاده شود. 74 | 75 | چهارم محفظه ها یک قلمرو خطای مشخص ارائه می‌دهند که به سیستم کلی اجازه می‌دهدکه با وجود از کارافتادن قسمتهای خاصی از آن، بازهم به شکل مطلوبی کار کند. مثلا کارگزار وب حتی در زمانی که محفظه ثبت وقایع دچار مشکل شده باشد، می‌تواند به کار خودش ادامه دهد. 76 | 77 | آخرین منفعت این است که محفظه یک واحد استقرار است که اجازه می‌دهد هر تکه از کارکرد برنامه مستقلا ارتقا پیدا کند و در صورت نیاز عقبگرد داشته باشد (گرچه باید ذکر شود که این منفعت یک روی منفی هم دارد-ماتریس تست برای سیستم کلی باید تمام ترکیبات نسخ محفظه را که ممکن است در محیط عملیاتی دیده شوند را در نظر بگیرد که می‌تواند بزرگ شود چون مجموعه محفظه ها نمی‌توانند به شکل کاملا مستقل ارتقاء یابند.البته با وجود اینکه یک برنامه کاملا یکپارچه این مشکل را ندارد، سیستمهای محفظه-مبنا راحتتر تست می‌شوند چون از اجزای کوچکتری ساخته می‌شوند که می‌توانند مستقلا تست شوند). 78 | 79 | توجه شود که این پنج منفعت در تمام الگوهایی که در ادامه این مقاله می آید هم وجود دارد. 80 | 81 | الگوی سفیر 82 | --- 83 | 84 | الگوی بعدی که ما مشاهده کردیم، الگوی سفیر است. محفظه های سفیر ارتباطات را از و به محفظه اصلی میانجیگری می‌کنند. برای مثال یک برنامه نویس می‌تواند یک برنامه را که با پروتکل memcache صحبت می‌کند را با یک محفظه سفیر twemproxy جفت کند. برنامه احساس می‌کند که دارد با یک نسخه memcache روی کامپیوتر محلی صحبت می‌کند در حالی که twemproxy درخواستها را بین چندین نسخه memcached که روی گره های دیگر نصب شده اند توزیع می‌کند. این الگوی محفظه ای زندگی برنامه نویس را به سه طریق ساده می‌کند: 85 | 86 | آنها فقط لازم است به شکلی فکر کنند و برنامه بنویسند که انگار به یک سرور روی ماشین محلی وصل هستند. 87 | 88 | آنها می توانند برنامه اشان را با یک نسخه memcached روی سرور محلی تست کنند بدون اینکه از محفظه سفیر استفاده کنند و آنها می‌توانند از سفیر twemproxy با برنامه های دیگر که به زبانهای دیگر نوشته شده اند استفاده کنند. 89 | 90 | امکان وجود محفظه های سفیر به خاطر این است که محفظه‌های روی یک ماشین، یک واسط شبکه محلی را با هم به اشتراک می‌گذارند. نمونه ای از این الگو در شکل زیر نمایش داده شده است. 91 | 92 | 93 | الگوی مبدل 94 | --- 95 | 96 | آخرین الگوی تک-گره‌ای که ما مشاهده کردیم، الگوی مبدل است. برخلاف الگوی سفیر، که به برنامه یک دید ساده از دنیای خارج ارائه می‌دهد، مبدلها یک دید ساده شده و یکسان از برنامه‌ها به دنیا بیرون ارائه می‌دهند. آنها این کار را با یکسان سازی خروجی ها و واسطهای بین چند محفظه انجام می‌دهند. یک مثال عینی از الگوی مبدل، مبدلهایی هستند که مطمئن می‌شوند که تمام محفظه ها در یک سیستم، یک واسط مانیتورینگ یکسان دارند.برنامه ها امروزه از گستره وسیعی از روشها برای برون دهی معیارهایشان (مثلJMXوstatsd)استفاده می‌کنند. 97 | 98 | اما برای یک ابزار مانیتورینگ، ساده تر است که معیارها را از یک مجموعه ناهمگون از برنامه ها جمع آوری، تجمیع و ارائه کند، وقتی که تمام این برنامه ها یک واسط یکسان برای این کار در اختیارش قرار دهند. 99 | 100 | در گوگل ما با کمک استفاده از قراردادهای کدنویسی به این مقصود رسیده‌ایم اما این تنها زمانی ممکن است که خودتان برنامه را از ابتدا ساخته باشید. الگوی مبدل به دنیای ناهمگون کدهای به ارث رسیده و نرم افزار های متن باز اجازه می‌دهد که بدون نیاز به تغییر در کد برنامه اصلی، یک واسط یکسان ارائه دهند. محفظه اصلی می‌تواند با محفظه مبدل از طریق شبکه محلی یا از طریق فضای ذخیره‌سازی محلیِ به اشتراک گذاشته، ارتباط برقرار کند. شکل زیر نمونه از الگوی مبدل را نشان میدهد. 101 | 102 | باید به این نکته توجه داشت که با وجود اینکه ابزارهای مانیتورینگی وجود دارند که می‌توانند بین چندین نوع از برنامه‌ها ارتباط برقرار کنند، آنها از کدهای مختص آن برنامه کاربردی در سیستم مانیتورنگشان استفاده میکنند که این کار باعث ایجاد یک نوع تفکیک وظایف نامناسب‌تر می‌شود. 103 | 104 | الگوهای کاربردهای چند گره‌ای 105 | --- 106 | 107 | گذشته از سطح محفظه های همکار در یک ماشین، محفظه‌ها ساخت برنامه های چندگره‌ای را نیز آسانتر کرده اند .ما در ادامه سه نمونه از این الگوهای سیستم توزیع شده را توضیح می‌دهیم. مانند الگوهای قسمتهای قبل ما همچنان نیاز به پشتیبانی از انتزاع Pod داریم. 108 | 109 | الگوی انتخاب رهبر 110 | --- 111 | 112 | یکی از رایج ترین مسائل در سیستمهای توزیع شده، انتخاب رهبر است. در حالیکه به طور گسترده ای از رونوشت‌برداری برای تقسیم بار بین چندین نمونه یکسان از یک مولفه استفاده می‌شود یک نمونه استفاده پیچیده تر، در کاربردهایی است که نیاز است یکی از این مجموعه رونوشتها به عنوان رهبر انتخاب شود. 113 | 114 | رونوشتهای دیگر در صورتیکه رهبر دچار مشکل شود، بالقوه و به سرعت می‌توانند به عنوان رهبر جدید انتخاب شوند. همچنین ممکن است در یک سیستم چندین انتخاب رهبر به شکل موازی اجرا شود برای مثال برای مشخص کردن رهبر هر تکه از سیستم. 115 | 116 | کتابخانه های زیادی برای اجرای الگوریتم انتخاب رهبر وجود دارد. فهم و استفاده درست از اغلب آنها سخت است. به اضافه اینکه آنها در زبانهای برنامه نویسی خاصی نوشته شده اند. یک راه جایگزین برای اتصال کتابخانه انتخاب رهبر به برنامه، استفاده از محفظه انتخاب رهبر است. مجموعه‌ای از محفظه های انتخاب رهبر هر کدام با یک نسخه از برنامه که نیاز به انتخاب رهبر دارد، متصل است و می‌توانند از بین خودشان رهبر انتخاب کنند. می‌توانند یک API ساده HTTP روی ماشین محلی برای هر محفظه برنامه کاربردی که نیاز به انتخاب رهبر دارد ارائه دهند (مثلا becomeLeader ,renewLeadership …). 117 | 118 | این محفظه های انتخاب رهبر یک بار، توسط افراد متخصص در این حوزه پیچیده،ساخته می‌شوند و سپس واسط ساده آنها می‌تواند توسط برنامه نویسان، بدون توجه به زبان برنامه نویسیشان استفاده شود. این کار بهترین نوع انتزاع و کپسوله سازیدر مهندسی نرم افزار را ارائه می‌دهد. 119 | 120 | الگوی صف کارها 121 | --- 122 | 123 | گرچه صفهای کار مثل انتخاب رهبر یک موضوعی هستند که به خوبی مطالعه شده اند و بسیاری از چارچوبها برای پیاده سازی آنها وجود دارد، آنها نیز یک نمونه از الگوهای سیستمهای توزیع شده هستند که از معماری محفظه-گرا می‌توانند سود ببرند. در سیستمهای قبلی غیر محفظه‌ای، چارچوب، برنامه ها را محدود به یک زبان برنامه نویسی می‌کرد (مثلا Celery برای Python) یا اینکه توزیع کارها بر عهده پیاده ساز گذاشته می‌شد(مثلCondor) 124 | در دسترس بودن فراوان محفظه هایی که واسطهای run و mount را پیاده‌سازی کرده‌اند، پیاده‌سازی یک چارچوب کلی صف کار، که می‌تواند کد دلخواه، که به شکل محفظه بسته بندی شده، و داده دلخواه را بگیرد و یک سیستم کامل صف کارها را بسازد، را بسیار ساده کرده است. 125 | 126 | برنامه نویس تنها نیاز دارد که یک محفظه بسازد که بتواند فایل ورودی را از فایل سیستم بگیرد و آن را تبدیل کند به یک فایل خروجی، این محفظه می‌تواند یک مرحله از صف کار باشد. 127 | 128 | تمام کارهای دیگر در توسعه یک صف کار کامل می‌تواند با این چارچوب عام منظوره صف کار انجام شود و هر وقت که این سیستم مورد نیاز بود، می‌تواند استفاده مجدد شود شیوه‌ای که کد کاربر در این صف کار اشتراکی، ادغام می‌شود در شکل زیر نمایش داده شده است. 129 | 130 | الگوی پراکندگی/گردآوری 131 | --- 132 | 133 | آخرین الگوی سیستمهای توزیع شده که ما توضیح می‌دهیم الگوی پراکندگی/گردآوری است. در چنین سیستمی یک کاربر خارجی یک درخواست به یک گره ریشه یا پدر می‌فرستد. این ریشه درخواست را به تعداد زیادی از گره‌های برگ ارسال می‌کند تا پردازش را به شکل موازی انجام دهند. هر تکه از سیستم، قسمتی از دادهٔ پاسخ را برمی‌گرداند. ریشه، این داده ها را گردآوری می‌کند و به شکل یک پاسخ به درخواست اصلی به کاربر باز می‌گرداند. 134 | 135 | این الگو در موتورهای جستجو بسیار رایج است. توسعه چنین سیستم توزیع شده ای نیاز به استفاده از مقدار زیادی کد تکراری دارد شامل پخش کردن درخواست، گردآوری پاسخ‌ها، تعامل با کاربر و غیره. بیشتر قسمتهای این کد نسبتا عام منظوره هستند. بازهم همانند برنامه نویسی شی گرا می‌توانند به این شکل بازنویسی شوند که یک پیاده سازی ارائه شود که توسط هر محفظه دلخواهی تا زمانیکه یک واسط مشخص را پیاده سازی کنند، استفاده شود. 136 | 137 | به طور خاص برای پیاده سازی سیستم پراکنده‌ساز/گردآور کاربر باید دو محفظه ایجاد کند. محفظه ای که محاسبات گره های برگ را انجام می‌دهد. این محفظه محاسبات جزئی را انجام می‌دهد و نتایج مربوطه را برمی‌گرداند. محفظه دیگری که مسئول ادغام است، پاسخ محفظه های برگ را می‌گیرد و آنها را به شکل یک پاسخ واحد در می‌آورد و به کاربر بر می‌گرداند. با محفظه هایی که این واسطهای ساده را پیاده سازی می‌کنند، کاربر می‌تواند یک سیستم پراکنده‌ساز/گردآور با عمق دلخواه بسازد. 138 | 139 | کارهای مرتبط 140 | --- 141 | معماری های سرویس گرا(SOA) ویژگیهای مشترکی با سیستمهای توزیع شده محفظه-مبنا دارند. برای مثال هردو روی مولفه های قابل استفاده مجدد که واسطهای خوش تعریف دارند، که از طریق شبکه با هم در ارتباطند، تاکید می‌کنند. در سمت مخالف مولفه ها در سیستمهای soa گرایش دارند به این که درشت دانه تر باشند و به هم پیوستگی کمتری داشته باشندنسبت به الگوهای چند محفظه ای که ما توضیح دادیم. به اضافه مولفه ها در soa اغلب اَعمال مرتبط با کسب و کار را پیاده سازی می‌کنند در حالیکه مولفه هایی که که ما اینجا رویشان متمرکز شدیم بیشتر وابسته به کتابخانه های عام منظوره هستند که که ساخت سیستمهای توزیع شده را ساده تر می‌کنند. 142 | 143 | واژه ریزسرویس برای توضیح دادن انواع مولفه هایی که ما در این مقاله راجع بهشان بحث کردیم اخیرا پدیدار شده است. مفهوم واسط مدیریت استاندارد شده برای مولفه های مرتبط با شبکه پیشینه‌ای طولانی دارد که حداقل به SNMP باز می‌گردد. SNMP تمرکز اصلیش روی مدیریت مولفه های سخت افزاری است. هیچ استانداردی برای مدیریت ریزسرویسها/سیستمهای محفظه-مبنا هنوز وجود ندارد. 144 | 145 | با این وجود تعداد زیادی از سیستمهای مدیریت محفظه مثل Aurora, ECS, Docker Swarm, Kubernetes Marathon و Nomad توسعه یافته اند. تمام الگوریتمهای توزیع شده که ما در بخش آخر به آنها اشاره کردیم پیشینه ای طولانی دارند. پیاده سازی های انتخاب رهبر به سادگی از Github قابل دسترسی هستند. تعدادی از پیاده سازیهای صف کار وجود دارد مثلCelery و Amazon SQS. پراکنده‌ساز/گردآور به عنوان یک الگوی یکپارچه سازی معظم شناخته شده است. 146 | 147 | نتیجه گیری 148 | --- 149 | 150 | همانطور که برنامه نویسی شی گرا به پیدایش و دسته بندی "الگوهای طراحی”شی گرا انجامید، ما شاهد آن هستیم که معماریهای محفظه ای، ما را به سمت الگوهایی برای سیستمهای توزیع شده محفظه-مبنا هدایت می‌کنند. در این مقاله ما سه نوع از الگوهایی که مشاهده کرده‌ایم را نامگذاری و تعریف کردیم: 151 | 152 | الگوهای تک محفظه ای برای مدیریت سیستم، الگوهای تک گره ای برای محفظه های شدیدا به هم وابسته و الگوهای چند گره ای برای الگوریتمهای توزیع شده. در تمام موارد محفظه ها بسیاری از منافعی که اشیا در سیستمهای شی گرا ارائه می‌دهند را دارا هستند. مثل ساده سازی تقسیم پیاده سازی ها بین چندین تیم و استفاده مجدد از مولفه ها در بافتار جدید. به اضافه اینکه آنها بعضی فواید منحصر به فرد در سیستمهای توزیع شده به ما می‌دهند مثل امکان ارتقاء دادن مولفه ها به شکل مستقل، امکان نوشتن برنامه‌ها با مخلوطی از زبانهای برنامه نویسی و برای سیستم به شکل کلی که با وجود از کارافتادن قسمتهای خاصی از آن، بازهم به شکل مطلوبی کار کند. 153 | 154 | ما معتقدیم که مجموعه الگوهای محفظه ها رشد خواهند کرد و در سالهای پیش رو، آنها برنامه نویسی سیستمهای توزیع شده را به همان اندازه که شی گرایی در دهه های قبل برنامه نویسی را متحول کرد، متحول خواهند کرد. 155 | -------------------------------------------------------------------------------- /content/blog/docker-basic-concepts.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:55:02+04:30" 3 | draft = false 4 | title = "مفاهیم پایه ای داکر" 5 | 6 | +++ 7 | 8 | مفاهیم پایه ای داکر 9 | === 10 | 11 | مجموعه ابزارهای داکر به طور کلی توسعه و انتشار نرم افزارها را ساده میکند و این کار را از طریق فراهم کردن یک راه حل مناسب برای ساخت و به اشتراک گذاشتن تصویری قابل اجرا از یک برنامه کاربردی انجام میدهد. یک تصویر داکر همچنین بخشهای زیادی از سیستم عامل بجز هسته آن را شامل میشود. 12 | 13 | پیش از مطالعه این مطلب اگر در ضرورت استفاده از داکر تردید دارید میتوانید مقاله [چرا به داکر نیاز دارید](http://elastico.io/blog/why-you-need-docker.html) را مطالعه کنید. 14 | 15 | ## بخشهای اصلی اکوسیستم داکر 16 | 17 | مجموعه ابزارها و سرویسهای داکر را میتوان در سه بخش اصلی دسته بندی کرد: 18 | 19 | - **ساخت:** تولید یک تصویر (image) داکر که یک برنامه کاربردی به همراه تمام وابستگی های آن را در خود دارد. هر تصویر معمولا با ساز و کار `docker build` از روی یک `Dockerfile` و با اضافه کردن یک یا چند برنامه کاربردی به یک تصویر پایه ساخته میشود. 20 | - **اجرا:** کانتینرها (container) که در واقع تصاویر در حال اجرا هستند را میتوان به سادگی و با سرعت زیاد در تعداد بالا ایجاد و سپس متوقف و یا کاملا حذف کرد. مزیت اصلی داکر در این بخش جداسازی کامل این کانتینرها از یکدیگر در زمان اجراست، به طوری که هر یک از آنها گمان میکنند روی یک سیستم عامل کاملا جداگانه اجرا شده اند. 21 | 22 | - **انتشار:** تصاویر تولید شده در داکر از طریق سرویسی به نام registry و با کمک دستورات `docker push` و `docker pull` به آسانی قابل انتشار و به اشتراک گذاری هستند. همچنین سرویس آنلاین Docker Hub یک نمونه از این registry است که برای مصارف عمومی به صورت رایگان در اختیار کاربران قرار داده شده است. 23 | *لازم به یادآوری است که اگر در استفاده از این سرویس با مشکلاتی برای دانلود تصاویر مواجه شدید، میتوانید با تنظیم یک mirror به صورتی که در [این گروه](https://groups.google.com/forum/#!topic/software-taak/xRmFWrozRoo) گفته شده، دوباره امتحان کنید.* 24 | 25 | برای اینکه بتوانید با این سه جنبه از داکر کار کنید نیاز دارید برنامه موتور داکر به نام `docker daemon` را روی سیستم خودتان یا در یک ماشین مجازی اجرا کنید. این برنامه در واقع تمام عملیاتهای درخواست شده از داکر برای ساخت، اجرا و انتشار کانتینرها را انجام میدهد. علاوه بر این، شما به یک برنامه دیگر به نام docker client نیاز دارید که دستورات را از خط فرمان میگیرد و به موتور داکر منتقل میکند. در سیستم عامل لینوکس هر دو این برنامه ها در قالب یک فایل اجرایی به نام `docker` به شما ارایه میشود. اما در سیستم عاملهای دیگر مانند ویندوز و Mac OS X تنها بخش client در فایل اجرایی `docker` وجود دارد و شما نیاز دارید سرویس `docker daemon‍` را در یک سیستم عامل جداگانه، که در حال حاضر باید حتما لینوکس باشد، اجرا کنید. ابزار ماشین داکر (docker machine) که پایین تر درباره آن توضیح داده شده است در این مورد به شما کمک میکند. 26 | 27 | به طور کلی هر زمان که با دستور `docker run‍` کانتینری را اجرا میکنید، موتور داکر ابتدا تصویر مورد نظر را از یک registry، مانند ‌Docker Hub، دانلود میکند و سپس یک کانتینر جدید از آن تصویر ایجاد میکند. البته اگر دوباره اقدام به ساخت یک کانتینر از روی همان تصویر کنید دیگر نیازی به دانلود کردن آن نیست و بنابراین دفعات بعدی این کار با سرعت بالاتری انجام میشود. 28 | 29 | ## ساختار یک تصویر داکر (docker image) 30 | 31 | هر تصویر داکر از یک سری لایه تشکیل شده است که هر لایه تنها شامل تغییرات نسبت به لایه قبلیست. موتور داکر در زمان اجرا از فایل سیستمهایی استفاده میکند که این امکان را فراهم میکنند تا تمامی این لایه ها به صورت یک ساختار فایل یکپارچه در اختیار کانتینر قرار داده شود. 32 | 33 | یکی از برتریهای داکر نسبت به فناوری ماشینهای مجازی استفاده از همین ساختار لایه ای برای تصاویر است. این لایه بندی باعث میشود زمانی که شما یک تصویر جدید را از روی یک تصویر قبلی میسازید داکر نیازی به کپی کردن همه فایلهای تصویر قبلی ندارد و تنها کافیست که لایه جدید، شامل تغییرات فایلها را، بسازد. به این ترتیب هر لایه پس از یکبار ساخته شدن دیگر تغییر نمیکند و به راحتی میتوان آن را بین تصاویر گوناگون به اشتراک گذاشت بدون اینکه نیاز باشد داکر کاری برای جلوگیری از تداخل فایلها انجام دهد. این روش مصرف دیسک سخت را به میزان زیادی بهینه میکند. 34 | 35 | در این مدل هر تصویر داکر از یک تصویر پایه (base image)‌ ساخته میشود. این تصویر پایه ممکن است یک سیستم عامل سبک مانند لینوکس Debian یا Alpine باشد، ولی حتی میتوان از یک سیستم عامل بزرگ مانند Ubuntu شروع کرد، اگر چه این کار معمولا توصیه نمی شود. این تصویر در صورتی که از قبل روی سیستم شما وجود نداشته باشد در زمان اولین ساخت از داکر هاب دانلود میشود. سپس شما میتوانید تصاویر بعدی را حتی از روی تصاویری که خودتان قبلا تولید کرده اید بسازید. 36 | 37 | به عنوان مثال شما میتوانید از یک تصویر Debian شروع کنید و سپس با نصب محیط اجرایی جاوا و یک وب سرور مانند Tomcat روی آن، تصویری بسازید که پایه تصاویر بعدی شما شود. برای این کار نیاز به نوشتن یک فایل به نام `Dockerfile` دارید که شامل یک تصویر پایه و سپس دستوراتی برای نصب برنامه ها، اضافه کردن فایلها و در انتها مشخص کردن دستوریست که در زمان ایجاد کانتینر اجرا خواهد شد. در نهایت وقتی شما با استفاده از دستور `docker build` درخواست تولید این تصویر را صادر میکنید داکر دستورات داخل این فایل را اجرا میکند و به این ترتیب لایه های جدیدی برای تصویر شما تولید میشود. سپس شما میتوانید این تصویر را با دستور `docker push` به یک registry بفرستید و نام آن را با دیگران به اشتراک بگذارید تا به راحتی بتوانند آن را دانلود و اجرا کنند. 38 | 39 | ## ساختار یک کانتینر (container) 40 | 41 | یک کانتینر از اجرای یک یا چند پردازه (process) بر روی فایلهای یک تصویر بدست می آید. داکر اطلاعات بیشتری مانند اینکه کدام پورتهای شبکه (network port) باید در اختیار این پردازه ها قرار بگیرد را هم مدیریت میکند. از مهمترین نکات این است که تغییراتی که هر کانتینر روی فایلهای خود ایجاد میکند به صورت جداگانه و در یک لایه جدید ذخیره میشود و به این ترتیب تصویر اصلی هیچگاه تغییر نمیکند. 42 | 43 | با توقف یک کانتینر با استفاده از دستور `docker stop‍` پردازه های آن متوقف میشوند ولی تغییرات فایلهای آن همچنان قابل بازیابی هستند تا زمانی که لایه های متعلق به آن کانتینر با دستور `docker rm` کاملا حذف شوند. برای آشنایی بیشتر با دستورات داکر میتوانید مقاله [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. 44 | 45 | همانطور که گفته شد مزیت اصلی داکر در جداسازی کامل فضای پردازه های کانتینرهای مختلف از یکدیگر است، به طوری که هر کانتینر تصور میکند تنها پردازه های خودش در حال حاضر در حال اجرا هستند. این جداسازی همچنین شامل فایل سیستم، فضای کاربری، پشته شبکه (network stack)‌ و بخشهای دیگری از سیستم عامل میشود. از این طریق داکر امکان قرار دادن محدودیتهای گوناگون روی دسترسی هر کانتینر به منابع مشترک سیستم را فراهم میکند. 46 | 47 | ## ماشین داکر (docker machine) 48 | 49 | ماشین داکر یک ابزار جانبیست که ایجاد و مدیریت موتورهای داکر روی رایانه های شخصی یا سرویسهای ابری را تسهیل میکند. به طور مختصر این ابزار امکان ایجاد سرورهایی را فراهم میکند که موتور داکر را بر روی خود دارند و به سادگی اجازه میدهد از طریق پیکربندی docker client روی ماشین خودتان به این سرورها متصل شوید و با موتور داکر کار کنید. 50 | 51 | برای آشنایی بیشتر با این فناوری میتوانید [وبینار تاک با موضوع آشنایی مقدماتی با داکر](http://taakestan.com/index.php/2012-09-09-10-30-14/53-docker) را مشاهده کنید یا [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. -------------------------------------------------------------------------------- /content/blog/docker-compose-intro-part1.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-02-27T23:05:01+04:30" 3 | draft = false 4 | title = "آشنایی با داکر کامپوز (Docker Compose) - بخش اول" 5 | 6 | +++ 7 | 8 | 9 | آشنایی با داکر کامپوز (Docker Compose) - بخش اول 10 | === 11 | 12 | ابزار Docker Compose (با نام قبلی Fig) ابزاری متن باز برای خودکارسازی کار با کانتینرهاست که ابتدا توسط تیم Orchard ایجاد و سپس در سال ۲۰۱۴ توسط شرکت داکر خریداری شد. برای درک بهتر این ابزار لازم است قدری با [مفاهیم اولیه داکر](http://elastico.io/blog/docker-basic-concepts.html) آشنایی داشته باشید که میتوانید در همین سایت درباره آن بیشتر مطالعه کنید. 13 | 14 | داکر کامپوز برای تعریف و اجرای برنامه هایی که از چند کانتینر تشکیل شده اند بکار میرود. با استفاده از این ابزار میتوان یک یا چند کانتینر را به همراه تمام پارامترهای لازم برای اجرای آنها در یک فایل YAML به نام کامپوزفایل (docker-compose.yml) تعریف کرد و سپس همه آنها را با استفاده از تنها یک دستور ایجاد و راه اندازی نمود. در این فایل هر یک از این کانتینرها یک سرویس نامیده میشود که تعریف دقیق آن به این صورت است: 15 | >هر سرویس یک کانتینر است که به شکلی با کانتینرهای دیگر در تعامل است و مشخصات زمان اجرای خاص خود را دارد. 16 | 17 | غالبا استفاده از داکر کامپوز یک فرآیند سه مرحله ایست: 18 | 19 | * تعریف محیط اجرای برنامه ها با داکرفایل (Dockerfile) که در نتیجه در هر جایی امکان اجرا دارد. 20 | * تعریف سرویسهای معادل هر برنامه در کامپوزفایل که در نتیجه امکان اجرای آنها در یک محیط ایزوله در کنار یکدیگر بوجود می آید. 21 | * اجرای دستور `docker-compose up` که در نتیجه برنامه شما با همه سرویسهایش اجرا میشود. 22 | 23 | در اینجا نمونه ای از یک کامپوزفایل (نسخه ۲) نمایش داده شده که از دو سرویس تشکیل شده است: 24 | ``` 25 | version: '2' 26 | services: 27 | web: 28 | build: . 29 | ports: 30 | - "5000:5000" 31 | volumes: 32 | - .:/code 33 | links: 34 | - redis 35 | redis: 36 | image: hub.elastico.io/library/redis 37 | ``` 38 | اولین سرویس که web نام دارد از روی یک داکرفایل در پوشه جاری (که مسیر آن با `.`  مشخص شده است) ساخته میشود و دومین سرویس آخرین نسخه از پایگاه داده های redis است که از روی تصویر آماده آن اجرا میشود. توضیحات بیشتر در خصوص ساختار کامپوزفایل در مقالات بعدی از این سری ارایه خواهد شد. 39 | 40 | در واقع ابزار داکر کامپوز دستوراتی برای مدیریت چرخه عمر کانتینرها دارد که امکانات زیر را فراهم میکند: 41 | 42 | * اجرا، توقف و بازتولید سرویسها 43 | * مشاهده وضعیت سرویسهای در حال اجرا 44 | * مشاهده خروجی (لاگ) سرویسهای در حال اجرا 45 | 46 | در این سری از مقالات قصد داریم نحوه نصب داکر کامپوز و سپس شیوه استفاده از آن را برای ایجاد و راه اندازی یک کاربرد چندکانتینری ساده توضیح دهیم. این مقاله تنها به معرفی اولیه و شیوه نصب این ابزار میپردازد. 47 | 48 | نحوه نصب داکر کامپوز 49 | --- 50 | امکان نصب داکر کامپوز بر روی سیستم عاملهای لینوکس، ویندوز و مک وجود دارد و این کار از سه طریق ممکن است: نصب مستقیم فایل باینری، نصب از طریق داکر (در ویندوز و مک) و یا نصب از طریق یک بسته نرم افزاری Python Pip. 51 | 52 | نصب در لینوکس 53 | --- 54 | برای نصب داکر کامپوز در لینوکس باید فایل باینری آن را از گیت هاب دانلود کرده و سپس به یک فایل قابل اجرا تبدیل کنید. در تکه کد زیر نحوه انجام این کار با استفاده از دستور `curl` نمایش داده شده است. توجه کنید که داکر کامپوز تنها بر روی نسخه های ۶۴ بیتی لینوکس قابل اجراست: 55 | ``` 56 | $ sudo curl -L https://github.com/docker/compose/releases/ 57 | download/1.8.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose 58 | $ sudo chmod +x /usr/local/bin/docker-compose 59 | ``` 60 | 61 | نصب در مک (Mac OS X) 62 | --- 63 | داکر کامپوز در مک از طریق نصب بسته داکر برای مک (Docker for Mac) نصب میشود ولی در صورت تمایل میتوانید آن را به صورت جداگانه با استفاده از فایل باینری و اجرای دستورات زیر نصب کنید: 64 | ``` 65 | $ sudo bash -c "curl -L https://github.com/docker/compose/ 66 | releases/download/1.8.0/docker-compose-Darwin-x86_64 > /usr/local/bin/docker-compose" 67 | $ sudo chmod +x /usr/local/bin/docker-compose 68 | ``` 69 | 70 | نصب در ویندوز 71 | --- 72 | داکر کامپوز در ویندوز به همراه بسته داکر برای ویندوز (Docker for Windows) فراهم شده است. 73 | 74 | نصب از طریق یک بسته نرم افزاری پایتون (Python Pip) 75 | --- 76 | اگر بر روی سیستم عامل دیگری قصد نصب داکر کامپوز را دارید یا ترجیح می دهید نصب را با استفاده از یک بسته نرم افزاری انجام دهید می توانید از Python Pip استفاده کنید. برای اینکار باید ابتدا Python Pip را نصب کنید و سپس با استفاده از دستور زیر داکر کامپوز را نصب کنید: 77 | 78 | ``` 79 | $ sudo pip install -U docker-compose 80 | ``` 81 | 82 | مقالات بعدی از این سری به زودی در همین سایت منتشر خواهد شد. 83 | -------------------------------------------------------------------------------- /content/blog/docker-faq.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-06-24T18:18:41+04:30" 3 | draft = false 4 | title = "پرسش و پاسخهای متداول درباره داکر" 5 | 6 | +++ 7 | 8 | 9 | پرسش و پاسخهای متداول درباره داکر 10 | === 11 | 12 | داکر چه کاربردهایی دارد؟ 13 | --- 14 | داکر نصب و پیکربندی (configuration) نرم افزارهای مختلف را راحت و سریع میکند به حدی که نصب و اجرای یک نرم افزار بسیار پیچیدهٔ سمت سرور تنها چند دقیقه بیشتر طول نمیکشد. همچنین معماری داکر به گونه ایست که میتوان با آن به سادگی نسخه های کاملا متفاوت از یک نرم افزار را همزمان بر روی یک سیستم عامل اجرا کرد بدون اینکه این نسخه ها با یکدیگر تداخلی داشته باشند. 15 | 16 | در واقع از دید نرم افزاری که در یک کانتینر (container) اجرا میشود تفاوتهای سیستم عاملهای گوناگون پنهان مانده و محیطی قابل پیش بینی برای آن فراهم میشود که کار توسعه نرم افزار را بسیار راحت میکند. 17 | 18 | در مجموع این ویژگیها به برنامه سازان امکان میدهد نرم افزارهایشان را بدون دغدغه های ناشی از تنوع در محیط اجرا، در قالب یک تصویر داکر (docker image) منتشر کنند و اطمینان داشته باشند کاربران آنها در اجرای آن موفق خواهند بود. برای توضیحات بیشتر در این باره میتوانید [مقالهٔ «چرا به داکر نیاز دارید»](http://elastico.io/blog/why-you-need-docker.html) را مطالعه کنید. 19 | 20 | آیا برای اجرای کانتینرها به اینترنت نیاز است؟ 21 | --- 22 | برای اجرای یک کانتینر (container) نیاز دارید تصویر داکر (docker image) آنرا روی سیستم عامل خود داشته باشید. [ساده ترین راه برای بدست آوردن تصاویر داکر](http://elastico.io/blog/how-to-run-official-images.html) دانلود کردن آنها از یک سرویس اینترنتی به نام هاب است. 23 | 24 | البته اگر قبلا تصویر نرم افزار مورد نظر خود را دانلود کرده باشید یا با کمک دستورات `export` و `import` آنرا در دسترس داکر قرار داده باشید، برای اجرای آن دیگر به اینترنت نیازی نیست. به این ترتیب میتوان از داکر برای نصب نرم افزارها روی سرورهای داخلی که خارج از فضای اینترنت قرار دارند نیز استفاده کرد. 25 | 26 | تفاوت داکر با ماشینهای مجازی چیست؟ 27 | --- 28 | اگرچه ماشینهای مجازی (Virtual Machine) مانند داکر امکان جداسازی برنامه ها و اجرای همزمان آنها در یک سیستم عامل میزبان را فراهم میکنند و از این جهت شباهتهایی دارند ولی معماری و پیاده سازی آنها بسیار متفاوت است. 29 | 30 | داکر بر خلاف ماشینهای مجازی برای هر کانتینر یک هسته (kernel) جداگانه اجرا نمیکند و در واقع تمام کانتینرهایی که روی یک سیستم عامل اجرا میشوند از هستهٔ همان سیستم عامل به صورت مشترک استفاده میکنند. این معماری باعث شده است که اجرای کانتینرها به مراتب سریعتر و سبکتر از ماشینهای مجازیست و نیاز به منابع کمتری مانند حافظه و دیسک دارد. 31 | 32 | از طرف دیگر یکی از بهترین روشهای (best practice) استفاده از داکر این است که در یک کانتینر فقط یک نوع برنامه کاربردی اجرا شود و این بر خلاف ماشینهای مجازیست که به دلیل سربار زیاد نمیتوان به راحتی این تکنیک را بر روی آنها پیاده کرد. با بکارگیری این روش داکر میتواند مسئولیت نظارت بر برنامه های اجرا شده را به راحتی برعهده بگیرد و مثلا در شرایطی که برنامه ای دچار مشکل میشود آنرا دوباره اجرا (restart) کند. 33 | 34 | داکر چگونه به فرآیند بروزرسانی نرم افزارها کمک میکند؟ 35 | --- 36 | از آنجایی که بر اساس بهترین روشهای (best practice) استفاده از داکر توصیه میشود کانتینرها به صورت تغییرناپذیر (immutable) پیاده سازی شوند، فرآیند بروزرسانی یک نرم افزار تحت داکر عملا تنها شامل دو دستور برای توقف (stop) نسخه قبلی و اجرای (run) نسخه جدید است. 37 | 38 | چون این نسخه ها در کانتینرهایی کاملا مجزا اجرا میشوند هیچ تاثیری روی یکدیگر ندارند و در صورت نیاز حتی میتوان دو نسخه کاملا متفاوت را همزمان روی یک سیستم عامل اجرا کرد. 39 | 40 | در مواردی که کانتینری برای اجرا نیاز به ذخیره و نگهداری داده ها روی دیسک داشته باشد، مانند نرم افزارهای پایگاه داده ها، میتوان این داده ها را بر روی دیسکی خارج از کانتینر ذخیره کرد که پس از توقف کانتینر قبلی از بین نمیرود و همچنان قابل استفاده برای نسخه جدید است. 41 | 42 | پیاده سازی این روش به این ترتیب است که با استفاده از امکانی به نام والیوم (volume) این فضا به صورت پوشه ای از دیسک میزبان یا حتی در یک دیسک کاملا مجزا در اختیار کانتینر قرار داده میشود. در این موارد به هنگام بروزرسانی باید دقت شود که آیا نسخه جدید با همان ساختار فایل قبلی قابل اجراست یا نیاز به یک فرآیند مهاجرت داده ها (data migration) بین دو نسخه قدیم و جدید وجود دارد. 43 | 44 | آیا داکر فقط روی سیستم عامل لینوکس (Linux) اجرا میشود؟ 45 | --- 46 | خیر. داکر در حال حاضر علاوه بر لینوکس روی سیستم عاملهای سری مک (MacOS X) و نسخه های ویندوز ۱۰ (Windows 10) و ویندوز سرور ۲۰۱۶ (Windows Server 2016) از مجموعه سیستم عاملهای شرکت مایکروسافت نیز اجرا میشود. البته فنآوری داکر به طور خاص با استفاده از ویژگیهای هسته لینوکس، مانند namespaces و cgroups، طراحی و پیاده سازی شده است و سیستم عاملهای دیگر با استفاده از ماشینهای مجازی یا شبیه سازی این ویژگیها روی هسته خودشان توان اجرای داکر را فراهم کرده اند. 47 | 48 | 49 | چگونه میتوان یک تصویر داکر (docker image) برای اجرای برنامه ای تولید کرد؟ 50 | --- 51 | بهترین راه برای ساخت تصاویر داکر نوشتن فایلی به نام Dockerfile و سپس اجرای دستور `docker build` است. برای آشنایی بیشتر با این روش میتوانید مقاله [«روش نوشتن Dockerfile»](http://elastico.io/blog/how-to-write-dockerfile.html) را مطالعه کنید. 52 | 53 | رجیستری (registry) داکر چیست؟ 54 | --- 55 | رجیستری داکر نرم افزاری برای نگهداری و به اشتراک گذاشتن تصاویر (image) داکر است که بسته به پیاده سازی آن ممکن است به صورت عمومی برای تمامی کاربران در اینترنت یا تنها به صورت خصوصی در شبکه داخلی یک شرکت قابل دسترسی باشد. برای آشنایی بیشتر با این مفهوم میتوانید مقاله [«رجیستری (Registry) و مخزن (Repository) داکر چیست»](http://elastico.io/blog/what-is-registry-repository.html) را مطالعه کنید. 56 | 57 | در نهایت اگر به صورت جدی تر قصد استفاده از فنآوری داکر را دارید خوب است با ابزارهای [داکر کامپوز](http://elastico.io/blog/docker-compose-intro-part1.html) و [کوبرنتیس](http://elastico.io/blog/what-is-kubernetes-why-need-it.html) آشنا شده و به [گروه داکر در تلگرام](https://telegram.me/joinchat/DBSHvj6Jmd0FYWfhyvrnvw) ملحق شوید. 58 | -------------------------------------------------------------------------------- /content/blog/how-to-run-official-images.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-06-17T18:18:41+04:30" 3 | draft = false 4 | title = "ساده ترین راه برای دانلود تصاویر رسمی داکر چیست؟" 5 | 6 | +++ 7 | 8 | 9 | ساده ترین راه برای دانلود تصاویر رسمی داکر چیست؟ 10 | === 11 | 12 | اگر با [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) آشنا هستید و قصد دارید برای پروژه بعدی خود از آن استفاده کنید، ممکن است برای دانلود تصاویر رسمی داکر (official docker images) به مشکلاتی برخورده باشید. 13 | 14 | ساده ترین و سریعترین راه در حال حاضر برای انجام این کار استفاده از سرویس الستیکو هاب است. به عنوان مثال برای اجرای یک سرور tomcat میتوانید دستور زیر را اجرا کنید: 15 | 16 | ``` 17 | docker run -ti hub.elastico.io/library/tomcat 18 | ``` 19 | 20 | یا برای اجرای یک پایگاه داده های mysql از طریق کانتینر رسمی آن میتوانید دستور زیر را بکار ببرید: 21 | 22 | ``` 23 | docker run -d --name=test-mysql -e MYSQL_ROOT_PASSWORD=passw123 hub.elastico.io/library/mysql 24 | ``` 25 | و سپس با استفاده از دستور زیر خروجی آن را بررسی کنید: 26 | 27 | ``` 28 | docker logs test-mysql 29 | ``` 30 | 31 | و در نهایت با کمک دستور زیر به آن متصل شوید: 32 | 33 | ``` 34 | docker run -it --rm --link test-mysql:mysql hub.elastico.io/library/mysql sh -c 'exec mysql -h"$MYSQL_PORT_3306_TCP_ADDR" -P"$MYSQL_PORT_3306_TCP_PORT" -uroot -p"$MYSQL_ENV_MYSQL_ROOT_PASSWORD"' 35 | ``` 36 | 37 | سرویس الستیکو هاب به زودی امکان جستجوی این تصاویر را هم فراهم میکند ولی در حال حاضر میتوانید آنها را از طریق جستجو در داکر هاب (hub.docker.com) پیدا کرده و سپس با قرار دادن `hub.elastico.io/library` در ابتدای نام تصاویر آنها را به راحتی دریافت و اجرا کنید. 38 | 39 | جهت آشنایی بیشتر با داکر میتوانید مقاله [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید یا اگر به صورت جدی تر قصد استفاده از این فنآوری را دارید در راستای مدیریت بهتر کانتینرها با ابزارهای [داکر کامپوز](http://elastico.io/blog/docker-compose-intro-part1.html) و [کوبرنتیس](http://elastico.io/blog/what-is-kubernetes-why-need-it.html) آشنا شوید. 40 | -------------------------------------------------------------------------------- /content/blog/how-to-write-dockerfile.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:53+04:30" 3 | draft = false 4 | title = "روش نوشتن یک Dockerfile " 5 | 6 | +++ 7 | 8 | روش نوشتن یک Dockerfile 9 | === 10 | 11 | یکی از بهترین روشهای تولید یک تصویر داکر (docker image)، نوشتن یک Dockerfile و سپس استفاده از دستور `docker build` است. این روش به دلیل سادگی و سازگاری با متدولوژی زیرساخت به صورت کد (Infrastructure as Code) به متداولترین راه برای تولید تصاویر داکر تبدیل شده است. 12 | 13 | *جهت اجرای دستورات گفته شده در این مقاله نیاز دارید قبلا داکر را نصب کرده باشید. روش نصب داکر روی [ویندوز](http://elastico.io/blog/install-docker-windows.html) یا [لینوکس CentOS](http://elastico.io/blog/install-docker-centos7.html) را میتوانید در همین سایت مطالعه کنید. همچنین برای یادگیری بهتر این مطلب ممکن است آشنایی با [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) به شما کمک کند.* 14 | 15 | ## ساده ترین Dockerfile 16 | 17 | ساده ترین Dockerfile میتواند تنها شامل یک خط باشد که مشخص میکند کدام تصویر قرار است به عنوان تصویر پایه برای تولید یک تصویر جدید بکار گرفته شود. به عنوان مثال کافیست در یک پوشه فایلی با این محتویات و با نام `Dockerfile` ایجاد کنید: 18 | 19 | FROM debian:wheezy 20 | 21 | سپس میتوانید با اجرای دستور `docker build -t my-first-image $PWD` در همان پوشه، اولین تصویر داکر خود را بسازید. در این حالت تصویر جدید کاملا مشابه تصویر پایه خواهد بود، که در این مثال نسخه Wheezy از سیستم عامل Debian است. 22 | 23 | در نهایت با اجرای دستور `docker images` میتوانید تمامی تصاویر موجود روی ماشین داکر خودتان را لیست کنید که شامل تصویر جدید نیز میشود: 24 | 25 | $ docker images 26 | REPOSITORY TAG IMAGE ID CREATED SIZE 27 | debian wheezy 2e9c7e5da19c 12 days ago 84.92 MB 28 | my-first-image latest 2e9c7e5da19c 12 days ago 84.92 MB 29 | 30 | همانطور که مشاهده میکنید شناسه های (ID) هر دو این تصاویر دقیقا یکسان هستند و حتی با اینکه تصویر جدید لحظاتی قبل تولید شده است، زمان ایجاد آن چند روز قبل و همزمان با تصویر پایه نشان داده میشود. این بدین دلیل است که دستور `docker build‍` تشخیص میدهد که تصویر جدید هیچ تغییراتی نسبت به تصویر پایه ندارد و بنابراین نیازی به اختصاص فضا و شناسه جدید نیست. در واقع با این کار تنها یک نام جدید برای همان تصویر قبلی تولید شده است که این کار را میتوان با کمک دستور `docker tag` نیز به سادگی و بدون نیاز به Dockerfile انجام داد. 31 | 32 | ## اضافه کردن فایل به تصویر 33 | 34 | اگر فایلی مثلا به نام `test.sh` در همان پوشه داشته باشید میتوانید با اضافه کردن یک خط دیگر در Dockerfile این فایل را به مجموعه فایلهای موجود در تصویر خود اضافه کنید: 35 | 36 | FROM debian:wheezy 37 | COPY test.sh /test.sh 38 | 39 | در این حالت خروجی دستور `docker build` به صورت زیر خواهد بود: 40 | 41 | $ docker build -t my-second-image . 42 | Sending build context to Docker daemon 2.56 kB 43 | Step 1 : FROM debian:wheezy 44 | ---> 2e9c7e5da19c 45 | Step 2 : COPY test.sh /test.sh 46 | ---> 0ff656c325b7 47 | Removing intermediate container 32821b2cd6d4 48 | Successfully built 0ff656c325b7 49 | 50 | نکته قابل توجه در این خروجی وجود دو مرحله در ساخت این تصویر جدید است. حالا اگر لیست تصاویر موجود را مجددا بررسی کنید متوجه خواهید شد که تصویر جدید، به نام my-second-image، شناسه ای متفاوت از تصویر پایه دارد و در زمان جدیدتری نیز ساخته شده است: 51 | 52 | $ docker images 53 | REPOSITORY TAG IMAGE ID CREATED SIZE 54 | my-second-image latest 0ff656c325b7 7 minutes ago 84.92 MB 55 | debian wheezy 2e9c7e5da19c 12 days ago 84.92 MB 56 | my-first-image latest 2e9c7e5da19c 12 days ago 84.92 MB 57 | 58 | مشابه همین روش را میتوانید برای اضافه کردن یک پوشه به تصویر بکار ببرید. دقت کنید که حجم تصویر جدید بسته به تعداد و اندازه فایلهای اضافه شده بزرگتر از تصویر پایه خواهد شد. 59 | 60 | **نکته:** اگر بدون هیچ تغییری در هیچ یک از فایلها، دوباره اقدام به ساخت همین تصویر کنید متوجه خواهید شد که دفعه دوم فرآیند ساخت بسیار سریعتر و تقریبا به صورت آنی تمام میشود. علت این امر آن است که داکر برای هر مرحله یک تصویر میانی میسازد و تمامی این تصاویر میانی را به صورت موقت نگهداری میکند تا فرآیند ساخت را تسریع کند. 61 | 62 | برای اینکه محتویات تصویر جدید را مشاهده کنید و از وجود فایلهای خود مطمئن شوید میتوانید اقدام به اجرای یک پوسته (shell) در یک کانتینر از این تصویر کنید: 63 | 64 | $ docker run --rm -ti my-second-image /bin/sh 65 | # ls -l /test.sh 66 | -rw-r--r-- 1 root root 0 May 16 13:32 /test.sh 67 | 68 | در صورت نیاز برای آشنایی بیشتر با فرامین داکر میتوانید [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. 69 | 70 | همچنین لازم به ذکر است که دستور `COPY` مشابه قدیمی تری به نام `ADD` دارد که در حال حاضر کمتر استفاده میشود. این دو دستور تفاوتهایی با یکدیگر دارند، مانند اینکه در دستور `ADD` میتوان یک آدرس وب را بجای مبدا برای اضافه کردن یک فایل به تصویر استفاده کرد. 71 | 72 | ## نصب برنامه ها روی تصویر 73 | 74 | با استفاده از دستور `RUN` در یک Dockerfile میتوانید برنامه هایی را که در حال حاضر روی تصویر شما نصب نیستند به آن اضافه کنید. این دستور به طور کلی برای اجرای هر برنامه ای در **زمان ساخت تصویر** کاربرد دارد. به عنوان مثال Dockerfile زیر برنامه unzip را روی یک تصویر پایه نصب میکند: 75 | 76 | FROM debian:wheezy 77 | RUN apt-get update 78 | RUN apt-get install -y --no-install-recommends unzip 79 | RUN rm -rf /var/lib/apt/lists/* 80 | 81 | **نکته:** هدف از خط آخر که دستور `rm` را اجرا میکند حذف فایلهای غیرضروری از تصویر ساخته شده پس از نصب برنامه هاست تا حجم آن بیش از حد افزایش پیدا نکند. اما از آنجایی که هر دستور `RUN` در Dockerfile یک لایه جدید به تصویر اضافه میکند، بدون اینکه هیچ تغییری در لایه های قبلی بدهد، این هدف با این روش محقق نمیشود. 82 | 83 | اگر این تصویر را با اجرای دستور `docker build -t my-unzip-image $PWD` بسازید متوجه خواهید شد که ۴ مرحله طی میشود که منجر به ساخت ۴ لایه جدید خواهد شد. این روش در زمان توسعه یک Dockerfile بسیار مفید است زیرا هر بار که تغییری در فایلی بدهید و بخواهید تصویر خود را مجددا بسازید تنها دستوراتی که تغییر کرده اند اجرا خواهند شد و به این ترتیب فرآیند توسعه و عیب یابی با سرعت بیشتری پیش خواهد رفت. اما پس از اینکه از درستی فایل خود مطمئن شدید بهتر است برای بهینه کردن این تصویر آن را به صورت زیر بازنویسی کنید تا تنها یک دستور `RUN` در آن بکار گرفته شود: 84 | 85 | FROM debian:wheezy 86 | RUN apt-get update && \ 87 | apt-get install -y --no-install-recommends unzip && \ 88 | rm -rf /var/lib/apt/lists/* 89 | 90 | این روش تنها یک لایه به تصویر پایه اضافه میکند که منجر به ساخت تصویری کوچکتر با تعداد لایه های کمتر خواهد شد که برای انتشار و استفاده کاربران مناسبتر است. 91 | 92 | ## مشخص کردن یک برنامه پیش فرض برای کانتینر 93 | 94 | در مدل توصیه شده داکر، هر کانتینر بناست فقط پردازه هایی از یک نوع برنامه اجرایی را شامل شود. با کمک دستور `CMD` که معمولا در انتهای Dockerfile آورده میشود میتوان یک دستور اجرایی را به صورت پیش فرض برای یک تصویر مشخص کرد که این دستور در نهایت در **زمان اجرای یک کانتینر** از روی تصویر ساخته شده استفاده خواهد شد. به عنوان مثال Dockerfile زیر دستور `unzip` را برای اجرا روی تصویر مشخص میکند: 95 | 96 | FROM debian:wheezy 97 | RUN apt-get update && \ 98 | apt-get install -y --no-install-recommends unzip && \ 99 | rm -rf /var/lib/apt/lists/* 100 | CMD ["unzip"] 101 | 102 | پس از ساختن یک تصویر از روی این فایل با دستور `docker build -t my-unzip-image $PWD` و سپس اجرای یک کانتینر روی آن، خروجی به صورت زیر خواهد بود که نشان میدهد برنامه `unzip` با موفقیت اجرا شده است: 103 | 104 | $ docker run --rm -ti my-unzip-image 105 | UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP. 106 | Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir] 107 | Default action is to extract files in list, except those in xlist, to exdir; 108 | file[.zip] may be a wildcard. -Z => ZipInfo mode ("unzip -Z" for usage). 109 | ... 110 | 111 | دقت کنید که شما همچنان میتوانید در صورت نیاز برنامه های دیگری را به سادگی روی این تصویر اجرا کنید. برای این کار کافیست در انتهای دستور `docker run‍` نام برنامه اجرایی مورد نظرتان را ذکر کنید تا به جای دستور پیش فرض اجرا شود. 112 | 113 | **نکته:** دستور مشابه دیگری به نام `ENTRYPOINT` نیز برای مشخص کردن برنامه پیش فرض وجود دارد که تنها برای کاربردهای پیچیده تر توصیه میشود. 114 | 115 | در انتها اگر تمایل دارید با یک کاربرد واقعی از ‌Dockerfile آشنا شوید میتوانید [شیوه استفاده از داکر برای اجرای یک برنامه تحت وب جاوا](http://elastico.io/blog/jboss-docker-tutorial.html) را مطالعه کنید. -------------------------------------------------------------------------------- /content/blog/install-docker-centos7.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:36+04:30" 3 | draft = false 4 | title = "شیوه نصب داکر روی لینوکس CentOS 7" 5 | 6 | +++ 7 | 8 | شیوه نصب داکر روی لینوکس CentOS 7 9 | === 10 | 11 | روش شرح داده شده در این مقاله برای نصب داکر بر مبنای نسخه های باینری فراهم شده توسط خود شرکت داکر است. 12 | 13 | **پیش نیازها**: برای نصب داکر نیاز به نسخه ۶۴ بیتی از این سیستم عامل روی هسته 3.10 لینوکس یا بالاتر دارد. با اجرای دستور `uname -a` میتوانید از جزییات نسخه سیستم عامل خود مطمئن شوید. 14 | 15 | ## مراحل نصب با yum 16 | 17 | 1. ابتدا تمامی بسته های موجود را به روز کنید: 18 | 19 | sudo yum update 20 | 21 | 1. با اجرای دستور چند خطی زیر، آدرس مخزن بسته های داکر را به لیست مخازن سیستم خودتان اضافه کنید: 22 | 23 | sudo tee /etc/yum.repos.d/docker.repo <<-'EOF' 24 | [dockerrepo] 25 | name=Docker Repository 26 | baseurl=https://yum.dockerproject.org/repo/main/centos/$releasever/ 27 | enabled=1 28 | gpgcheck=1 29 | gpgkey=https://yum.dockerproject.org/gpg 30 | EOF 31 | 32 | 1. بسته داکر را نصب کنید: 33 | 34 | sudo yum install docker-engine 35 | 36 | 1. سرویس موتور داکر را اجرا کنید: 37 | 38 | sudo service docker start 39 | 40 | 1. با اجرای دستور زیر میتوانید مطمئن شوید که نصب به درستی انجام شده است: 41 | 42 | sudo docker run hub.elastico.io/library/hello-world 43 | 44 | *اگر به هنگام اجرای کانتینرها با مشکلاتی برای دانلود image ها از Docker Hub مواجه شدید، میتوانید با تنظیم یک mirror به صورتی که در [این گروه](https://groups.google.com/forum/#!topic/software-taak/xRmFWrozRoo) گفته شده، دوباره این کار را امتحان کنید.* 45 | 46 | در نهایت اگر میخواهید زمانیکه سیستم شما روشن میشود موتور داکر به صورت خودکار اجرا شود دستور زیر را اجرا کنید: 47 | 48 | sudo chkconfig docker on 49 | 50 | 51 | ## ایجاد یک گروه کاربری داکر (docker group) 52 | 53 | از آنجایی که سرویس داکر همیشه تحت کاربر `root` اجرا میشود و ارتباط با آن نیز از طریق خواندن و نوشتن در یک Unix socket است که متعلق به کاربر `root` می باشد، برای اجرای دستورات داکر نیاز به استفاده از `sudo‍` دارید. 54 | 55 | برای راحتی بیشتر در استفاده از دستورات داکر میتوانید گروهی به نام `docker` بسازید و کاربرانی را که قصد تعامل با موتور داکر دارند به این گروه اضافه کنید تا بتوانند بدون نیاز به `sudo` این کار را انجام دهند. در این حالت مالکیت Unix socket مربوطه نیز توسط سرویس داکر به این گروه کاربری داده میشود. 56 | 57 | **نکته:** دقت کنید که از نظر سطح امنیت، تمام کاربرانی که عضو گروه کاربری `docker` باشند عملا دسترسی `root` خواهند داشت. 58 | 59 | برای ایجاد این گروه و اضافه کردن یک کاربر به آن میتوانید مراحل زیر را طی کنید: 60 | 61 | 1. ابتدا گروه را ایجاد کنید: 62 | 63 | sudo groupadd docker 64 | 65 | 1. سرویس داکر را باز اجرا کنید: 66 | 67 | sudo service docker restart 68 | 69 | 1. سپس کاربر مورد نظرتان را به گروه اضافه کنید: 70 | 71 | sudo usermod -aG docker your-user 72 | 73 | 1. اگر قبلا با این کاربر وارد شده اید باید حالا خارج و دوباره وارد شوید. 74 | 75 | 1. با اجرای دستور زیر میتوانید مطمئن شوید همه چیز به درستی انجام شده است: 76 | 77 | docker run hub.elastico.io/library/hello-world 78 | 79 | برای آشنایی بیشتر با این فناوری میتوانید مقاله های [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) و [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. 80 | 81 | اگر فکر میکنید برای کار با داکر نیاز به کمک بیشتری دارید و یا علاقه مند هستید در آینده به یک سرور مجازی برای یادگیری آسانتر دسترسی داشته باشید میتوانید [این فرم کوتاه](https://docs.google.com/forms/d/1fIYtXM6UaV5pFRBAkNKVNHzBnUg157Sedxds5xYPWDI/viewform?usp=send_form) را پر کنید تا به یک گروه Slack به نام **elastico-users** که برای همین کار ایجاد شده است دعوت شوید. در آنجا میتوانید از اعضای با تجربه تر گروه هم کمک بگیرید. -------------------------------------------------------------------------------- /content/blog/install-docker-on-ubuntu-16.04.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-01-16T23:05:01+04:30" 3 | draft = false 4 | title = "نصب داکر بر روی اوبونتو Ubuntu 16.04 LTS" 5 | 6 | +++ 7 | 8 | 9 | نصب داکر بر روی اوبونتو (Ubuntu 16.04 LTS) 10 | === 11 | 12 | در این مطلب به چگونگی نصب داکر بر روی سیستم عامل اوبونتو می پردازیم. برای انجام دستورات زیر نیاز دارید که دسترسی root داشته باشید. 13 | 14 | از آنجا که بسته (package) موجود در مخزن اوبونتو 16.04 برای نصب داکر ممکن است آخرین نسخه نباشد، پیشنهاد می شود آخرین نسخه را از مخزن رسمی داکر دریافت کنید. 15 | 16 | برای این کار ابتدا اطلاعات تمام بسته ها را بروز رسانی کنید: 17 | 18 | ``` 19 | sudo apt-get update 20 | ``` 21 | 22 | حال برای نصب داکر، کلید GPG مخصوص مخزن رسمی داکر را به سیستم خود اضافه کنید: 23 | 24 | ``` 25 | sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D 26 | ``` 27 | سپس مخزن داکر را به منابع APT اضافه کنید تا بتوانید با کمک دستور `apt-get‍` بسته های این مخزن را نصب کنید: 28 | 29 | ``` 30 | sudo apt-add-repository 'deb https://apt.dockerproject.org/repo ubuntu-xenial main' 31 | ``` 32 | 33 | در قدم بعدی، دوباره اطلاعات بسته ها را که این بار شامل مخزن جدید داکر میشود بروز رسانی کنید: 34 | 35 | ``` 36 | sudo apt-get update 37 | ``` 38 | 39 | قبل از نصب مطمئن شوید که موتور داکر را از مخزن پروژه داکر دانلود می کنید، نه از مخزن پیش فرض اوبونتو. 40 | برای این کار دستور زیر را وارد کنید: 41 | 42 | ``` 43 | apt-cache policy docker-engine 44 | ``` 45 | و می بایست خروجی زیر را مشاهده کنید: 46 | 47 | ``` 48 | docker-engine: 49 | Installed: (none) 50 | Candidate: 1.11.1-0~xenial 51 | Version table: 52 | 1.11.1-0~xenial 500 53 | 500 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages 54 | 1.11.0-0~xenial 500 55 | 500 https://apt.dockerproject.org/repo ubuntu-xenial/main amd64 Packages 56 | ``` 57 | این پیام نشان میدهد که گزینه انتخابی برای نصب، مخزن پروژه داکر است. البته نسخه نشان داده شده برای شما ممکن است متفاوت باشد ولی آدرس مخزن باید حتما در سایت `apt.dockerproject.org` باشد. 58 | 59 | در نهایت، موتور داکر را نصب کنید: 60 | 61 | ``` 62 | sudo apt-get install -y docker-engine 63 | ``` 64 | زمانی که عملیات نصب به پایان رسید، موتور داکر به صورت خودکار اجرا شده و پردازه داکر برای اجرا در هنگام راه اندازی سیستم (boot) فعال شده است. با دستور زیر می توانید وضعیت اجرایی آن را چک کنید: 65 | ``` 66 | sudo systemctl status docker 67 | ``` 68 | نتایج باید مشابه زیر باشد که وضعیت سرویس را در حال اجرا و فعال نشان میدهد (Active & running): 69 | 70 | ``` 71 | ● docker.service - Docker Application Container Engine 72 | Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) 73 | Active: active (running) since Sun 2016-05-01 06:53:52 CDT; 1 weeks 3 days ago 74 | Docs: https://docs.docker.com 75 | Main PID: 749 (docker) 76 | ``` 77 | 78 | در این مرحله نصب داکر تمام شده است. 79 | 80 | 81 | ### اجرای دستورات داکر بدون نیاز به sudo 82 | 83 | برای اجرای دستورات داکر می بایست آنها را با کمک دستور `sudo` اجرا کنید و در واقع نیاز به سطح دسترسی root دارید. اگر تمایل دارید بتوانید این دستورات را بدون `sudo` اجرا کنید میتوانید نام کاربری خود را به گروه داکر که در حین نصب ساخته شده است، اضافه کنید. 84 | 85 | برای این منظور دستور زیر را پس از جایگزین کردن نام کاربری مورد نظرتان اجرا کنید: 86 | 87 | ``` 88 | sudo usermod -aG docker USERNAME 89 | ``` 90 | 91 | حال میتوانید دستورات داکر را بدون نیاز به `sudo` اجرا کنید، ولی دقت کنید که این کار در عمل به هر کاربری که عضو گروه `docker` شده باشد سطح دسترسی root میدهد. 92 | 93 | برای آشنایی بیشتر با این فناوری میتوانید مقاله های [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) و [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. 94 | 95 | -------------------------------------------------------------------------------- /content/blog/install-docker-windows.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:29+04:30" 3 | draft = false 4 | title = "نحوه نصب داکر روی ویندوز" 5 | 6 | +++ 7 | 8 | # نحوه نصب داکر روی ویندوز 9 | 10 | کاربران ویندوز میتوانند از Docker Toolbox برای نصب داکر استفاده کنند. Docker Toolbox ابزارهای زیر را در اختیار شما قرار میدهد: 11 | 12 | - ابزار خط فرمان داکر (Docker CLI) برای تعامل با موتور داکر (Docker Engine) جهت ایجاد و تعامل با کانتینرها 13 | - ابزار ماشین داکر (Docker Machine) برای ایجاد ماشینهای مجازی که امکان اجرای کانتینرها را روی ویندوز دارند 14 | - ابزار داکر کامپوز (Docker Compose) برای اجرای دستورات docker-compose 15 | - محیط واسط گرافیکی Kitematic 16 | - پوسته شروع سریع داکر (Docker QuickStart) برای ایجاد سریع یک خط فرمان آماده برای اجرای دستورات داکر 17 | - نرم افزار متن باز Oracle VM VirtualBox 18 | 19 | به خاطر اینکه موتور داکر (Docker Engine)‌ از ویژگیهای خاص هسته لینوکس استفاده میکند شما نمیتوانید آن را مستقیم روی ویندوز اجرا کنید. به همین دلیل نیاز است که ابتدا با استفاده از دستور ماشین داکر (`docker-machine`) یک ماشین مجازی کوچک لینوکس درست کنید و سپس از طریق آن داکر را اجرا کنید. 20 | 21 | ## قدم ۱: نسخه ویندوز خود را چک کنید 22 | 23 | برای اینکه بتوانید داکر را اجرا کنید، ماشین شما باید نسخه ۶۴ بیتی ویندوز ۷ یا بالاتر را داشته باشد. همچنین باید مطمئن شوید که امکان virtualization برای سیستم شما فعال شده است. 24 | 25 | برای اطمینان از داشتن این پیش نیازها، میتوانید کارهای زیر را انجام دهید: 26 | 27 | 1. به Control Panel در قسمت System and Security و بعد System بروید و نسخه ویندوز خود را چک کنید. 28 | 1. ابزار مایکروسافت برای تشخیص امکان virtualization را از [اینجا](https://www.microsoft.com/en-au/download/details.aspx?id=592) دانلود و نصب کنید. همچنین در ویندوز ۸ میتوانید این تنظیم را از طریق Start > Task Manager > Performance tab و در قسمت CPU مشاهده کنید. 29 | 1. با استفاده از راهنمایی [این مقاله](https://support.microsoft.com/en-us/kb/827218) میتوانید مطمئن شوید که نسخه ویندوز شما ۶۴ بیتی است. 30 | 31 | ## قدم ۲: جعبه ابزار داکر (Docker Toolbox) را نصب کنید 32 | 33 | اگر در حال حاضر نسخه ای از نرم افزار VirtualBox را نصب شده دارید نیازی نیست آن را دوباره نصب کنید، فقط لازم است هنگام نصب جعبه ابزار داکر آن را ببندید. 34 | 35 | 1. به صفحه [Docker Toolbox](https://www.docker.com/toolbox) بروید و آن را دانلود کنید. 36 | 2. برنامه Installer را اجرا کنید. اگر ویندوز از شما خواست که اجازه تغییر سیستم را به این برنامه بدهید، گزینه Yes را انتخاب کنید. 37 | 3. برای حالت پیش فرض، در مراحل بعدی گزینه Next را انتخاب کنید و در نهایت گزینه Install. 38 | 4. پس از نصب موفقیت آمیز، صفحه ای ظاهر میشود که در آن دکمه Finish وجود دارد و میتوانید آن را بفشارید. 39 | 40 | ## قدم ۳: نرم افزارهای نصب شده را بررسی کنید 41 | تمامی ابزارهای نصب شده، در پوشه Applications قرار میگیرند. در این مرحله آنها را یک به یک تست میکنیم: 42 | 43 | 1. روی Desktop و یا در پوشه Applications ابزار Docker Toolbox را پیدا کنید و آن را اجرا کنید. 44 | 1. این ابزار برای شما یک خط فرمان آماده برای اجرای دستورات داکر باز میکند. اگر سیستم از شما خواست که به VirtualBox اجازه تغییرات در سیستم را بدهید گزینه Yes را انتخاب کنید. این خط فرمان یک محیط `bash` که خاص لینوکس است را در ویندوز برای شما فراهم میکند چون مورد نیاز داکر است. 45 | 1. دستور `docker run hub.elastico.io/library/hello-world` را تایپ و اجرا کنید. 46 | 47 | اجرای کامل این دستور مدتی طول میکشد و اگر همه چیز به خوبی پیش برود خروجی زیر را مشاهده میکنید: 48 | 49 | $ docker run hub.elastico.io/library/hello-world 50 | Unable to find image 'hello-world:latest' locally 51 | Pulling repository hello-world 52 | 91c95931e552: Download complete 53 | a8219747be10: Download complete 54 | Status: Downloaded newer image for hello-world:latest 55 | Hello from Docker. 56 | This message shows that your installation appears to be working correctly. 57 | 58 | To generate this message, Docker took the following steps: 59 | 1. The Docker Engine CLI client contacted the Docker Engine daemon. 60 | 2. The Docker Engine daemon pulled the "hello-world" image from the Docker Hub. 61 | (Assuming it was not already locally available.) 62 | 3. The Docker Engine daemon created a new container from that image which runs the executable that produces the output you are currently reading. 63 | 4. The Docker Engine daemon streamed that output to the Docker Engine CLI client, which sent it to your terminal. 64 | 65 | To try something more ambitious, you can run an Ubuntu container with: 66 | $ docker run -it hub.elastico.io/library/ubuntu bash 67 | 68 | For more examples and ideas, visit: 69 | https://docs.docker.com/userguide/ 70 | 71 | با دیدن این خروجی میتوانید مطمئن شوید که عمل نصب به درستی انجام شده و جعبه ابزار داکر شما قابل استفاده است. 72 | 73 | اگر به هنگام اجرای کانتینرها با مشکلاتی برای دانلود image ها از Docker Hub مواجه شدید، میتوانید با تنظیم یک mirror به صورتی که در [این گروه](https://groups.google.com/forum/#!topic/software-taak/xRmFWrozRoo) گفته شده، دوباره این کار را امتحان کنید. 74 | اگر فکر میکنید برای کار با داکر نیاز به کمک بیشتری دارید و یا علاقه مند هستید که در آینده به یک سرور مجازی برای یادگیری داکر دسترسی داشته باشید میتوانید [این فرم کوتاه](https://docs.google.com/forms/d/1fIYtXM6UaV5pFRBAkNKVNHzBnUg157Sedxds5xYPWDI/viewform?usp=send_form) را پر کنید تا به یک گروه Slack به نام **elastico-users** که برای همین کار ایجاد شده است دعوت شوید. در آنجا میتوانید از اعضای با تجربه تر گروه هم کمک بگیرید. 75 | -------------------------------------------------------------------------------- /content/blog/java-springboot-docker.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-07-01T14:54:29+04:30" 3 | draft = false 4 | title = "توسعه و اجرای یک پروژه جاوایی با Spring Boot و داکر (Docker)" 5 | 6 | +++ 7 | 8 | توسعه و اجرای یک پروژه جاوایی با Spring Boot و داکر (Docker) 9 | === 10 | 11 | از آنجایی که استفاده از فنآوری داکر هر روز در حال گسترش است و به نظر میرسد به زودی تبدیل به بستر استاندارد اجرای نرم افزارهای سمت سرور خواهد شد، در این مقاله سعی داریم روش اجرای یک برنامه جاوایی مبتنی بر Spirng Boot را همراه با جزییات کافی و به صورت مرحله به مرحله به کمک داکر شرح دهیم. حتی اگر قبلا با داکر کار کرده اید امیدواریم این مقاله ایده های خوبی برای روشهای بهینه استفاده از آن به شما بدهد. 12 | 13 | *مطالعه این مقاله نیاز به آشنایی قبلی با داکر ندارد ولی جهت اجرای دستورات آن نیاز دارید حداقل داکر را نصب کرده باشید. برای این کار میتوانید روش نصب داکر روی [ویندوز](http://elastico.io/blog/install-docker-windows.html)، [لینوکس CentOS](http://elastico.io/blog/install-docker-centos7.html) یا [لینوکس Ubuntu](http://elastico.io/blog/install-docker-on-ubuntu-16.04.html) را مطالعه کنید. همچنین برای یادگیری بهتر این مطلب ممکن است آشنایی با [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) به شما کمک کند.* 14 | 15 | 16 | مطالب این نوشته به بخشهای زیر تقسیم شده است: 17 | 18 | - ایجاد یک پروژه جاوایی ساده مبتنی بر Spring Boot 19 | - ساخت یک تصویر (Image) داکر برای این پروژه 20 | - اجرای تصویر (Image) بوسیله موتور داکر 21 | 22 | 23 | ایجاد پروژه جاوایی مبتنی بر Spring Boot 24 | --- 25 | ابتدا یک پوشه به نام ‍`gs-spring-boot-docker` برای این پروژه ایجاد کرده و سپس پوشه های داخلی زیر را درون آن بسازید: 26 | 27 | ``` 28 | src => main => java => hello 29 | ``` 30 | 31 | این کار را در سیستم عاملهای لینوکس یا Mac OS با یک دستور مثل این میتوان انجام داد: 32 | 33 | ``` 34 | mkdir -p src/main/java/hello 35 | ``` 36 | 37 | سپس در پوشه `gs-spring-boot-docker` یک فایل متنی با نام `pom.xml` ایجاد کنید و محتوای آنرا مطابق زیر پر نمایید: 38 | ``` 39 | 40 | 42 | 4.0.0 43 | org.springframework 44 | gs-spring-boot-docker 45 | 0.1.0 46 | 47 | org.springframework.boot 48 | spring-boot-starter-parent 49 | 1.5.2.RELEASE 50 | 51 | 52 | 1.8 53 | 54 | 55 | 56 | org.springframework.boot 57 | spring-boot-starter-web 58 | 59 | 60 | org.springframework.boot 61 | spring-boot-starter-test 62 | test 63 | 64 | 65 | 66 | 67 | 68 | org.springframework.boot 69 | spring-boot-maven-plugin 70 | 71 | 72 | 73 | 74 | ``` 75 | 76 | سپس یک کلاس با نام Application در فایل `src/main/java/hello/Application.java` ایجاد کرده و محتوای آنرا بصورت زیر قرار دهید: 77 | 78 | ``` 79 | package hello; 80 | 81 | import org.springframework.boot.SpringApplication; 82 | import org.springframework.boot.autoconfigure.SpringBootApplication; 83 | import org.springframework.web.bind.annotation.RequestMapping; 84 | import org.springframework.web.bind.annotation.RestController; 85 | 86 | @SpringBootApplication 87 | @RestController 88 | public class Application { 89 | @RequestMapping("/") 90 | public String home() { 91 | return "Hello Docker World"; 92 | } 93 | public static void main(String[] args) { 94 | SpringApplication.run(Application.class, args); 95 | } 96 | } 97 | ``` 98 | 99 | همانطور که مشاهده میکنید در این کلاس، متدی به نام `home` با استفاده از `RequestMapping` برای دریافت درخواست های سرور روی آدرس `/` یعنی آدرس اصلی سایت قرار داده شده است. در واقع بعد از اجرای این برنامه، آدرس زیر مقدار Hello Docker World را به مرورگر بر میگرداند: http://localhost:8080 100 | 101 | حال کافیست این پروژه را با ابزار Maven برای اولین بار بسازید. این کار هم از طریق IDE و هم از خط فرمان امکانپذیر است. 102 | 103 | اگر ابزار Maven را روی سیستم خود دارید کافیست در خط فرمان به پوشه‌‌ اصلی پروژه یعنی `gs-spring-boot-docker` بروید و دستور زیر را اجرا کنید: 104 | 105 | ``` 106 | mvn package 107 | ``` 108 | 109 | ولی اگر ابزار Maven را تابحال روی سیستم خود نصب نکرده اید، داکر میتواند به راحتی و با یک دستور برای شما آن را دانلود و اجرا کند: 110 | 111 | ``` 112 | docker run --rm -ti \ 113 | --net host \ 114 | --volume "${HOME}"/.m2:/root/.m2 \ 115 | --volume "${PWD}":/usr/src/mymaven \ 116 | --workdir /usr/src/mymaven \ 117 | hub.elastico.io/library/maven:3-jdk-8 \ 118 | mvn package 119 | ``` 120 | 121 | اگر به تازگی با داکر آشنا شده اید ممکن است این دستور به نظر شما کمی پیچیده برسد ولی مطالعه مقاله [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) به شما در فهم آن کمک میکند. 122 | 123 | پس از اجرای موفق این دستور تمام کتابخانه های مورد نیاز چارچوب Spring Boot دانلود و فایل نهایی این پروژه نیز ساخته شده است. 124 | 125 | اگر جاوا روی سیستم شما نصب شده است برای اجرای برنامه دستور زیر را وارد کنید: 126 | 127 | ``` 128 | java -jar target/gs-spring-boot-docker-0.1.0.jar 129 | ``` 130 | 131 | ولی اگر جاوا را تابحال نصب نکرده اید میتوانید مجدد از داکر برای این کار براحتی کمک بگیرید: 132 | 133 | ``` 134 | docker run --rm -ti \ 135 | --publish 8080:8080 \ 136 | --volume "${PWD}":/usr/src/myapp \ 137 | --workdir /usr/src/myapp \ 138 | hub.elastico.io/library/openjdk:8-jdk \ 139 | java -jar target/gs-spring-boot-docker-0.1.0.jar 140 | ``` 141 | 142 | با این کار برنامه اجرا شده و در مسیر http://localhost:8080 میتوانید خروجی آنرا مشاهده کنید. 143 | 144 | 145 | در مرحله بعدی از فایل ساخته شده در این مرحله که `target/gs-spring-boot-docker-0.1.0.jar` نام دارد برای ایجاد یک تصویر داکر استفاده خواهیم کرد تا امکان انتشار این برنامه فراهم شده و اجرای آن توسط کاربران آسانتر شود. 146 | 147 | ساخت یک تصویر (Image) داکر برای این پروژه 148 | --- 149 | در پوشه اصلی پروژه فایلی با نام `Dockerfile` بسازید و محتوای انرا بصورت زیر پر کنید: 150 | ``` 151 | FROM hub.elastico.io/library/openjdk:8 152 | 153 | VOLUME /tmp 154 | 155 | COPY target/gs-spring-boot-docker-0.1.0.jar /app.jar 156 | RUN sh -c 'touch /app.jar' 157 | 158 | EXPOSE 8080 159 | 160 | ENV JAVA_OPTS="" 161 | ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -jar /app.jar" ] 162 | ``` 163 | در دستورات بالا از یک تصویر داکر که در کتابخانه هاب الستیکو موجود است به عنوان تصویر پایه استفاده کرده ایم که این کار نیاز به نصب jdk را کاملا برطرف میکند. سپس یک volume با نام tmp ایجاد کرده ایم که به عنوان پوشه کاری (working directory) برای سرور tomcat واقع در spring boot در نظر گرفته میشود. 164 | 165 | در خط سوم jar فایل ساخته شده را با نام `app.jar` به داخل کانتینر کپی میکنیم. در قسمت بعدی بوسیله اجرای دستور touch به فایل خود زمان تغییرات اضافه میکنیم زیرا نداشتن زمان آخرین تغییر (modification time) در برخی موارد باعث جلوگیری از اجرای فایل ها توسط tomcat میشود. سپس بوسیله دستور Expose، پورت 8080 را برای ارتباط با بیرون کانتینر در نظر میگیریم. 166 | در انتها نیز فرمان اجرایی کانتینر را مشخص میکنیم. 167 | 168 | برای آشنایی بیشتر با این ساختار میتوانید مقاله [روش نوشتن یک Dockerfile](http://elastico.io/blog/how-to-write-dockerfile.html) را مطالعه کنید. 169 | 170 | حال با اجرای دستور زیر از این فایل برای ایجاد تصویر داکر استفاده میکنیم: 171 | 172 | ``` 173 | docker build -f Dockerfile -t spring-boot-docker . 174 | ``` 175 | 176 | دستور `docker build` برای ساخت یک تصویر از روی Dockerfile استفاده میشود. در دستور فوق پارامتر `t` برای تعیین tag که در واقع نام تصویر ساخته شده است بکار گرفته میشود. دقت کنید که نقطه در انتهای خط برای آدرس دهی در مسیر جاری جهت یافتن داکرفایل است. 177 | 178 | بعد از اجرای موفق دستور بالا میتوانید تصویر ساخته شده را در لیست خروجی فرمان زیر به عنوان یک تصویر داکر که آماده اجراست مشاهده کنید: 179 | 180 | ``` 181 | docker images 182 | ``` 183 | 184 | اجرای تصویر (Image) بوسیله موتور داکر 185 | --- 186 | سپس با دستور زیر میتوانید کانتینر خود را بر روی پورت 8080 اجرا کنید: 187 | 188 | ``` 189 | docker run -ti -p 8080:8080 spring-boot-docker 190 | ``` 191 | 192 | و از طریق آدرس http://localhost:8080 صفحه وب این کانتینر اجرایی خود را مشاهده کنید. 193 | 194 | به دلیل استفاد از پارامترهای `ti` این کانتینر در پیش زمینه (foreground) اجرا میشود که باعث میشود با فشردن دکمه های Ctrl+C بتوانید اجرای آنرا متوقف کنید. 195 | 196 | 197 | اگر قصد دارید این کانتینر در پس زمینه (background) به اجرای خود ادامه دهد میتوانید به جای آن از پارامتر `d` استفاده کنید: 198 | 199 | ``` 200 | docker run -d -p 8080:8080 --name my-app spring-boot-docker 201 | ``` 202 | 203 | در این حالت برای دیدن لاگهای برنامه میتوانید از دستور زیر کمک بگیرید: 204 | 205 | ``` 206 | docker logs my-app 207 | ``` 208 | 209 | و در نهایت با اجرای دستورات زیر این کانتینر را متوقف و سپس حذف کنید: 210 | 211 | ``` 212 | docker stop my-app 213 | docker rm my-app 214 | ``` 215 | 216 | حال اگر به صورت جدی تر قصد استفاده از فنآوری داکر را دارید میتوانید با ابزارهای [داکر کامپوز](http://elastico.io/blog/docker-compose-intro-part1.html) و [کوبرنتیس](http://elastico.io/blog/what-is-kubernetes-why-need-it.html) آشنا شده و به [گروه داکر در تلگرام](https://telegram.me/joinchat/DBSHvj6Jmd0FYWfhyvrnvw) ملحق شوید. 217 | -------------------------------------------------------------------------------- /content/blog/jboss-docker-tutorial.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:22+04:30" 3 | draft = false 4 | title = "شیوه استفاده از داکر برای اجرای یک برنامه تحت وب جاوا" 5 | 6 | +++ 7 | 8 | ## شیوه استفاده از داکر برای اجرای یک برنامه تحت وب جاوا 9 | 10 | برای اجرای این مثال نیاز دارید ابتدا داکر را نصب کرده باشید. [طریقه نصب داکر روی ویندوز](http://elastico.io/blog/install-docker-windows.html) را میتوانید در همین سایت مطالعه کنید. 11 | 12 | همچنین تمامی کدها و فایلهای مورد استفاده در این راهنما در گیت هاب در دسترس شماست: 13 | https://github.com/etcinitd/wildfly-docker-deployment-example 14 | 15 | با فرض اینکه برنامه جاوایی خود را کامپایل کرده و به صورت یک فایل war درآورده اید، برای اجرای آن با استفاده از ابزار داکر میتوانید مراحل زیر را طی کنید. برای راحتی شما یک فایل war به صورت نمونه از قبل فراهم شده است. 16 | 17 | - این راهنما از نسخه ۱۰ سرور جی باس (jboss/wildfly) روی داکر استفاده میکند. ابتدا یک فایل با نام `Dockerfile` و با این محتویات ایجاد کنید: 18 | 19 | FROM jboss/wildfly:10.0.0.Final 20 | ADD node-info.war /opt/jboss/wildfly/standalone/deployments/ 21 | 22 | این فایل مخصوص داکر است و برای ساخت یک تصویر (image) داکر که برنامه جاوایی مورد نظر شما را در خود دارد استفاده میشود. 23 | 24 | خط اول این فایل تصویر پایه (base image) را مشخص میکند که در این مثال سرور jboss/wildfly از کتابخانه داکر است. توضیحات بیشتر راجع به این تصویر خاص و نسخه های متفاوت آن را میتوانید در [صفحه سایت داکر هاب](https://hub.docker.com/r/jboss/wildfly) مشاهده کنید. 25 | 26 | خط دوم فایل war را که حاوی برنامه جاواست و از قبل ساخته شده، به این تصویر اضافه میکند و در آدرس مورد نظر برای سرور جی باس در داخل کانتینر قرار میدهد. بجای `node-info.war` میتوانید نام فایل war برنامه خودتان را بنویسید. 27 | 28 | *نکته جانبی:* به طور کلی در داکر هر تصویر (image) میتواند به عنوان پایه ای برای تصاویر جدید بکار رود و به این ترتیب لایه های متعددی از تصاویر یک تصویر نهایی را تشکیل میدهند. این ویژگی یکی از قابلیتهای مهم و اصلی داکر برای تولید و پخش ساده و سریع تصاویر است چون برای تولید یا انتقال یک تصویر تنها نیاز به ایجاد یا ارسال تفاوتهای بین دو تصویر است که به حجمی بسیار کمتر از تک تک تصاویر نیاز دارد. 29 | 30 | - فایل war برنامه خود را، که در مثال ما `node-info.war` نام دارد، در همان پوشه ای که `Dockerfile` قرار دارد کپی کنید. 31 | 32 | - در همان پوشه، تصویر (image) داکر را با اجرای دستور زیر بسازید. دقت کنید که در این صورت نام تصویر تولید شده wildfly-app خواهد بود: 33 | 34 | docker build --tag=wildfly-app . 35 | 36 | - در نهایت، کانتینر را با استفاده از دستور زیر اجرا کنید. این کار برنامه شما را در زمان شروع به کار کانتینر به صورت خودکار روی پرت (port) شماره 8080 اجرا میکند: `docker run -it -p 8080:8080 wildfly-app` 37 | 38 | - برای تست برنامه، اگر از ابزار docker-machine استفاده میکنید، آدرس IP ماشین مجازی داکر خودتان را به این طریق پیدا کنید: 39 | 40 | $ docker-machine ls 41 | NAME ACTIVE DRIVER STATE URL 42 | default virtualbox Running tcp://:2376 43 | 44 | - سپس با قرار دادن آدرس IP مرحله قبل در مرورگر، یا ابزاری مانند curl به صورت زیر، میتوانید صفحه وب برنامه جاوایی اجرا شده را مشاهده کنید: 45 | 46 | $ curl http://:8080/node-info/ 47 | Hostname: 4e3daa7ea20f 48 | Java Runtime: OpenJDK Runtime Environment 1.8.0_71-b15 49 | OS: Linux amd64 4.0.9-boot2docker 50 | 51 | 52 | اگر به هنگام اجرای کانتینرها با مشکلاتی برای دانلود image ها از Docker Hub مواجه شدید، میتوانید با تنظیم یک mirror به صورتی که در [این گروه](https://groups.google.com/forum/#!topic/software-taak/xRmFWrozRoo) گفته شده، دوباره این کار را امتحان کنید. 53 | 54 | اگر فکر میکنید برای کار با داکر نیاز به کمک بیشتری دارید و یا علاقه مند هستید که در آینده به یک سرور مجازی برای یادگیری داکر دسترسی داشته باشید میتوانید [این فرم کوتاه](https://docs.google.com/forms/d/1fIYtXM6UaV5pFRBAkNKVNHzBnUg157Sedxds5xYPWDI/viewform?usp=send_form) را پر کنید تا به یک گروه Slack به نام **elastico-users** که برای همین کار ایجاد شده است دعوت شوید. در آنجا میتوانید از اعضای با تجربه تر گروه هم کمک بگیرید. 55 | 56 | -------------------------------------------------------------------------------- /content/blog/kubernetes-expose-traffic.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-04-16T18:18:41+04:30" 3 | draft = false 4 | title = "چطور به یک برنامه که تحت Kubernetes اجرا شده است وصل شویم؟" 5 | 6 | +++ 7 | 8 | 9 | چطور به یک برنامه که تحت Kubernetes اجرا شده است وصل شویم؟ 10 | === 11 | 12 | در این مطلب قصد داریم بررسی کنیم که چطور میتوانیم با استفاده از Kubernetes به دنیای بیرون سرویس ارایه کنیم. اگر با مفاهیم اولیه Kubernetes آشنایی ندارید توصیه میکنیم ابتدا به [مقاله کوبرنتیس چیست](http://elastico.io/blog/what-is-kubernetes-why-need-it.html) نگاهی بیندازید. 13 | 14 | اگر با یکی از روشهای گفته شده در [این مقاله](https://kubernetes.io/docs/setup/pick-right-solution/) یک کلاستر کوبرنتیس راه اندازی کنید و چند سرویس هم بر روی آن اجرا کنید به زودی متوجه میشوید که روش های معمول ارایه سرویسهای وبی و توزیع بار (Load Balancing) مثلا با استفاده از Nginx برای اتصال به این سرویسها مشابه معمول کار نمیکند. علت این است که اجزای موجود در یک کلاستر Kubernetes به صورت پیش فرض از دنیای بیرون جدا هستند و فقط تحت شرایط خاصی میتوانند به درخواستهای دنیای خارج یا همان کاربران نهایی پاسخ بدهند. 15 | 16 | در ادامه به بررسی روش های موجود برای این کار بر روی سرورهای مجازی ابری و همچنین سرورهای سخت افزاری (bare-metal) میپردازیم. اما قبل از این کار یک سری مفاهیم ساده و اولیه را با هم مرور میکنیم. 17 | 18 | پاد (Pod) 19 | == 20 | در مجموعه واژگان کوبرنتیس به چند کانتینر که چرخه حیات (Life Cycle) یکسانی دارند و در واقع با هم و روی یک ماشین در کلاستر اجرا میشوند پاد (Pod) میگویند. پاد کوچکترین جزء در سیستم کوبرنتیس محسوب میشود که کانتینرهای موجود در آن به منابع سیستمی یکسانی دسترسی دارند. در اکثر مواقع پاد تنها از یک کانتینر تشکیل میشود. 21 | 22 | سرویس (Service) 23 | == 24 | سرویس در واقع یک لایه منطقی بر روی مجموعه ای از پادهاست. با استفاده از سرویس این امکان داده میشود که چندین پاد را انتخاب کرده و ترافیک ورودی را به یکی از آنها برسانیم. این پادها میتوانند نسخه های یکسانی از یک برنامه (جهت افزایش قابلیت اطمینان) و یا نسخه های متفاوتی از آن (جهت تست A/B) باشند. مثلا شما میتوانید برای تمام پادهای اجرا شده برای یک API خودتان یک سرویس ایجاد کنید که برنامه های دیگر به آن متصل شوند. از دید این برنامه ها فقط یک Endpoint برای این واسط کاربردی وجود دارد و آن سرویس شماست. 25 | 26 | سرویسها به طور پیش فرض فقط از داخل کلاستر قابل دسترسی هستند. هدف ما در این مقاله بیان شیوه های رساندن ترافیک به این سرویسها از دنیای خارج است. 27 | 28 | روش اول Node Port 29 | == 30 | 31 | در این روش یک پورت شبکه (port) بر روی سرورهای شما که جزئی از کلاستر هستند باز شده و شما میتوانید ترافیک را از طریق این پورت به سرویس برسانید. این پورت به صورت پیش فرض از بازه ۳۲۷۶۷-۳۰۰۰۰ انتخاب میشود که تقریبا در اکثر مواقع چیزی نیست که ما به دنبالش هستیم. چون مثلا ترافیک وب باید بر روی پورت ۸۰ یا ۴۴۳ باشد که این روش برای آن مناسب نیست. 32 | 33 | متن زیر نمونه ای از تعریف یک سرویس است که به همین روش پورت ۳۰۰۶۱ را به عنوان `nodePort` انتخاب کرده است: 34 | 35 | ``` 36 | kind: Service 37 | apiVersion: v1 38 | metadata: 39 | name: my-service 40 | spec: 41 | selector: 42 | app: MyApp 43 | type: NodePort 44 | ports: 45 | - protocol: TCP 46 | port: 80 47 | targetPort: 9376 48 | nodePort: 30061 49 | clusterIP: 10.0.171.239 50 | ``` 51 | 52 | روش دوم Load Balancer 53 | == 54 | در این روش کوبرنتیس از طریق اتصال به فراهم کننده بستر ابری برای سرویس شما یک IP در نظر میگیرد که با استفاده از این IP میتوانید از خارج کلاستر به سرویس خود متصل شوید. ایراد این روش این است که شما فقط میتوانید در صورتی از آن استفاده کنید که ارایه دهنده خدمات ابری شما این سرویس را ارایه کند. 55 | 56 | متن زیر نمونه ای از تعریف یک سرویس است که به این روش آدرس `78.11.24.19` را به عنوان `loadBalancerIP` پیشنهاد داده است ولی در نهایت بستر ابری آدرس `146.148.47.155` را در قسمت `status.loadBalancer` برای این سرویس انتخاب کرده است: 57 | 58 | ``` 59 | 60 | kind: Service 61 | apiVersion: v1 62 | metadata: 63 | name: my-service 64 | spec: 65 | selector: 66 | app: MyApp 67 | ports: 68 | - protocol: TCP 69 | port: 80 70 | targetPort: 9376 71 | nodePort: 30061 72 | clusterIP: 10.0.171.239 73 | loadBalancerIP: 78.11.24.19 74 | type: LoadBalancer 75 | status: 76 | loadBalancer: 77 | ingress: 78 | - ip: 146.148.47.155 79 | ``` 80 | 81 | روش سوم Port Proxy 82 | == 83 | 84 | از آنجایی که پادها بر خلاف سرویسها میتوانند به پورت های پایه دسترسی داشته باشند در این روش یک پاد بر روی یک نود (Node) ایجاد میشود که بر روی پورت مورد نظر ترافیک را دریافت و به سرویس مقصد منتقل میکند. برای اینکار از یک تصویر (Image) آماده داکر استفاده میشود که توانایی انتقال ترافیک را در لایه ۴ شبکه (لایه TCP و UDP)‌ داشته باشد. 85 | 86 | نمونه این پاد در زیر بر روی پورت ۵۳ سرویس DNS داخلی کوبرنتیس را ارایه میدهد: 87 | 88 | ‍‍ 89 | ``` 90 | apiVersion: v1 91 | kind: Pod 92 | metadata: 93 | name: dns-proxy 94 | spec: 95 | containers: 96 | - name: proxy-udp 97 | image: gcr.io/google_containers/proxy-to-service:v2 98 | args: [ "udp", "53", "kube-dns.default", "1" ] 99 | ports: 100 | - name: udp 101 | protocol: UDP 102 | containerPort: 53 103 | hostPort: 53 104 | - name: proxy-tcp 105 | image: gcr.io/google_containers/proxy-to-service:v2 106 | args: [ "tcp", "53", "kube-dns.default" ] 107 | ports: 108 | - name: tcp 109 | protocol: TCP 110 | containerPort: 53 111 | hostPort: 53 112 | 113 | ``` 114 | 115 | روش چهارم External IP ها 116 | == 117 | در حالتی که یک آدرس IP خاص از قبل وجود داشته باشد که بتواند به یک سرویس موجود در کلاستر ترافیک را برساند ما میتوانیم با استفاده از آن به سرویس مورد نظر متصل شویم: 118 | 119 | ``` 120 | kind: Service, 121 | apiVersion: v1, 122 | metadata: 123 | name: my-service 124 | spec: 125 | selector: 126 | app: MyApp 127 | ports: 128 | - name: http, 129 | protocol: TCP, 130 | port: 80, 131 | targetPort: 9376 132 | externalIPs: 133 | - 80.11.12.10 134 | ``` 135 | 136 | روش پنجم استفاده از Ingress ها 137 | == 138 | 139 | میتوان گفت پیشرفته ترین روش استفاده از Ingress است. اما ابتدا ببینیم Ingress چیست: 140 | 141 | 142 | Ingress 143 | == 144 | Ingress ها یک سری قوانین (rule) هستند که با تعریف آنها میتوانیم ترافیک را از بیرون به سرویس ها نگاشت (map) کنیم. در واقع این قوانین یک لایه منطقی تشکیل میدهند که با استفاده از آن نحوه فرستادن ترافیک خارجی به سرویس ها مشخص میشود. 145 | 146 | اما Ingress ها به تنهایی کار نمیکنند. در واقع برای اینکه این قوانین اجرایی شوند نیازمند Ingress Controller ها هستیم. Ingress Controller ها انواع مختلفی دارند. مثلا اکثر بسترهای ابری Ingress Controller های خاص خودشان را دارند که با استفاده از آنها میشود ترافیک را به راحتی بر روی سرویس فرستاد. همچنین ما میتوانیم Ingress Controller هایی را با استفاده از nginx و به صورت چند پاد بر روی خود کلاستر اجرا کنیم. 147 | 148 | مثلا به طریق زیر میتوانیم با کمک daemon set ها (یعنی پاد هایی که بر روی تمام نود ها اجرا میشوند) یک Ingress Controller از نوع nginx بر روی هر نود کلاستر اجرا کنیم: 149 | 150 | 151 | ``` 152 | apiVersion: extensions/v1beta1 153 | kind: DaemonSet 154 | metadata: 155 | name: nginx-ingress-lb 156 | labels: 157 | name: nginx-ingress-lb 158 | namespace: kube-system 159 | spec: 160 | template: 161 | metadata: 162 | labels: 163 | name: nginx-ingress-lb 164 | annotations: 165 | prometheus.io/port: '10254' 166 | prometheus.io/scrape: 'true' 167 | spec: 168 | terminationGracePeriodSeconds: 60 169 | containers: 170 | - image: gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.3 171 | name: nginx-ingress-lb 172 | readinessProbe: 173 | httpGet: 174 | path: /healthz 175 | port: 10254 176 | scheme: HTTP 177 | livenessProbe: 178 | httpGet: 179 | path: /healthz 180 | port: 10254 181 | scheme: HTTP 182 | initialDelaySeconds: 10 183 | timeoutSeconds: 1 184 | ports: 185 | - containerPort: 80 186 | hostPort: 80 187 | - containerPort: 443 188 | hostPort: 443 189 | env: 190 | - name: POD_NAME 191 | valueFrom: 192 | fieldRef: 193 | fieldPath: metadata.name 194 | - name: POD_NAMESPACE 195 | valueFrom: 196 | fieldRef: 197 | fieldPath: metadata.namespace 198 | args: 199 | - /nginx-ingress-controller 200 | - --default-backend-service=$(POD_NAMESPACE)/default-http-backend 201 | 202 | ``` 203 | 204 | دقت کنید که برای اینکار حتما باید یک پاسخ دهنده پیش فرض (default backend) وجود داشته باشد تا در صورتیکه کنترلر سرویسی برای پاسخ دادن به ترافیک وروردی پیدا نکرد از آن استفاده کند. البته نیازی نیست که حتما برای اجرای Ingress Controller ها از Daemon Set استفاده شود و میتوان از بقیه مکانیزمها مثل Deployment یا Replication Controller نیز استفاده کرد. 205 | 206 | حال که کنترلر ما اجرا شده است با تعریف Ingress ها میتوانیم ترافیک را بر روی پورت های مشترک بین سرویس ها تقسیم کنیم. مثلا: 207 | 208 | ``` 209 | apiVersion: extensions/v1beta1 210 | kind: Ingress 211 | metadata: 212 | name: test-ingress 213 | spec: 214 | rules: 215 | - http: 216 | paths: 217 | - path: /testpath 218 | backend: 219 | serviceName: test 220 | servicePort: 80 221 | 222 | ``` 223 | باعث میشود که با استفاده از مسیر `/testpath` بتوانیم به سرویس مورد نظر خود وصل شویم. 224 | 225 | یا با تعریف: 226 | ‍‍‍ 227 | ``` 228 | apiVersion: extensions/v1beta1 229 | kind: Ingress 230 | metadata: 231 | name: test 232 | spec: 233 | rules: 234 | - host: foo.bar.com 235 | http: 236 | paths: 237 | - backend: 238 | serviceName: s1 239 | servicePort: 80 240 | - host: bar.foo.com 241 | http: 242 | paths: 243 | - backend: 244 | serviceName: s2 245 | servicePort: 80 246 | 247 | ``` 248 | 249 | میتوان به سرویسهای مختلف بر اساس نام هاست (host) وصل شد. مثلا در نمونه بالا با اتصال به آدرس `http://foo.bar.com` میتوان به سرویس `s1` درخواست فرستاد. 250 | 251 | 252 | برای آشنایی بیشتر با این فنآوری میتوانید [ارایه ضبط شده کوبرنتیس](http://taakestan.com/index.php/2012-09-09-10-30-14/55-2016-08-30-kubernetes-docker-conf-tehran) در همایش داکر تهران را بر روی سایت تاک مشاهده کنید. 253 | 254 | نویسنده: میعاد ابرین 255 | [LinkedIn](https://www.linkedin.com/in/miad-abrin-73718558) - 256 | [Github](https://github.com/miadabrin) - 257 | [Stackoverflow](http://stackoverflow.com/users/1923516/miad-abrin) 258 | 259 | ویرایش: امیر مقیمی 260 | -------------------------------------------------------------------------------- /content/blog/use-gosu-not-sudo.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-11-16T14:54:13+04:30" 3 | draft = false 4 | title = "چرا بجای sudo بهتر است از gosu استفاده کنید؟" 5 | 6 | +++ 7 | 8 | چرا بجای sudo بهتر است از gosu استفاده کنید؟ 9 | === 10 | 11 | *جهت اجرای دستورات گفته شده در این مقاله نیاز دارید قبلا داکر را نصب کرده باشید. روش نصب داکر روی [ویندوز](http://elastico.io/blog/install-docker-windows.html) یا [لینوکس CentOS](http://elastico.io/blog/install-docker-centos7.html) را میتوانید در همین سایت مطالعه کنید. همچنین برای یادگیری بهتر این مطلب ممکن است آشنایی با [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) به شما کمک کند.* 12 | 13 | ابزار سنتی لینوکس برای اجرای دستورات تحت یک کاربر خاص sudo نام دارد و به احتمال زیاد شما تابحال به دفعات از آن استفاده کرده اید. اگر چه sudo ابزار قوی و کاراییست، محدودیتهایی دارد که آنرا برای استفاده در کانتینرها غیر ایده آل میکند. به عنوان مثال، اگر دستور `sudo ps aux` را در یک کانتینر Ubuntu اجرا کنید خروجی آن به صورت زیر خواهد بود: 14 | 15 | ``` 16 | $ docker run --rm hub.elastico.io/library/ubuntu:trusty sudo ps aux 17 | USER PID ... COMMAND 18 | root 1 sudo ps aux 19 | root 5 ps aux 20 | ``` 21 | 22 | همانطور که مشاهده میکنید در اینجا دو برنامه در داخل کانتینر در حال اجرا هستند، یکی sudo و دیگری دستوری که با استفاده از آن اجرا کردیم. یکی از مشکلاتی که در این حالت ایجاد میشود این است که سیگنالهایی که به کانتینر شما فرستاده شود بجای پردازه اصلی که برنامه مورد نظر شماست، به پردازه sudo فرستاده میشود. 23 | 24 | حالا اگر همان دستور قبلی یعنی `ps aux` را با کمک ابزار gosu که روی یک کانتینر Ubuntu نصب شده است اجرا کنید نتیجه به شکل دیگری خواهد شد: 25 | 26 | ``` 27 | $ docker run --rm amouat/ubuntu-with-gosu gosu root ps aux 28 | USER PID ... COMMAND 29 | root 1 ps aux 30 | ``` 31 | 32 | همانطور که مشاهده میکنید تنها یک پردازه در داخل کانتینر در حال اجراست که برنامه مورد نظر ماست و اثری از gosu نیست. مهمتر اینکه شناسه این پردازه (PID) شماره ۱ است یعنی تمامی سیگنالهایی که به این کانتینر فرستاده شود به این پردازه خواهد رسید و مشکلات sudo را نخواهید داشت. 33 | 34 | با کمک ابزار gosu، یکی از روشهایی که بتوانید به راحتی برنامه مورد نظرتان را در داخل کانتینر و تحت یک کاربر خاص اجرا کنید استفاده از یک اسکریپت bash به صورت زیر به عنوان entry-point است: 35 | 36 | ``` 37 | #!/bin/bash 38 | set -e 39 | if [ "$1" = 'myprogram' ]; then 40 | chown -R myuser . 41 | exec gosu myuser "$@" 42 | fi 43 | exec "$@" 44 | ``` 45 | 46 | بکارگیری exec و gosu به طور همزمان تضمین میکند که برنامه شما به عنوان پردازه شماره ۱ در داخل کانتینر اجرا خواهد شد. 47 | -------------------------------------------------------------------------------- /content/blog/useful-docker-commands.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:13+04:30" 3 | draft = false 4 | title = "دستورات پرکاربرد داکر" 5 | 6 | +++ 7 | 8 | دستورات پرکاربرد داکر 9 | === 10 | 11 | در این مقاله سعی میکنیم با دستورات بسیار پرکاربرد داکر آشنا شویم. 12 | 13 | 14 | جهت یادگیری بهتر و امتحان کردن این دستورات نیاز دارید ابتدا داکر را نصب کرده باشید. میتوانید [طریقه نصب داکر روی ویندوز](http://elastico.io/blog/install-docker-windows.html) را در همین سایت مطالعه کنید یا در صورت تمایل برای دسترسی مجانی و موقت به یک سرور مجازی لینوکس برای یادگیری داکر [این فرم کوتاه](https://docs.google.com/forms/d/1fIYtXM6UaV5pFRBAkNKVNHzBnUg157Sedxds5xYPWDI/viewform?usp=send_form) را پر کنید. 15 | 16 | ## دستور pull 17 | 18 | برای دانلود کردن یک تصویر (image) جدید میتوانید از دستور pull استفاده کنید. این دستور تمام لایه های یک تصویر را، در صورتی که قبلا روی ماشین شما دانلود نشده باشند، از کتابخانه داکر دانلود میکند: 19 | 20 | docker pull hub.elastico.io/library/debian 21 | 22 | این نکته که تصاویر داکر میتوانند لایه های مشترک با یکدیگر داشته باشند تاثیر زیادی در افزایش سرعت دانلود و اجرای کانتینرها دارد. 23 | 24 | ## دستور run 25 | 26 | برای ایجاد یک کانتینر جدید و اجرای یک shell که به شما یک خط فرمان (command line) تازه در داخل همان کانتینر میدهد، میتوانید دستور زیر را اجرا کنید: 27 | 28 | docker run -ti --name my_container_name hub.elastico.io/library/debian /bin/bash 29 | 30 | پارامتر `-ti` باعث میشود که کانتینر شما به محض اجرای دستور، که در این مثال `/bin/bash` است، خروجیهای آن را برای شما چاپ کند و در صورت نیاز منتظر ورودی از صفحه کلید بماند. در این حالت با خروج از این shell، مثلا با اجرای دستور `exit`، اجرای کانتینر نیز متوقف میشود. 31 | 32 | اگر بخواهید فایلهای کانتینر بلافاصله پس از توقف، از روی سیستم کاملا حذف شوند میتوانید از پارامتر `--rm` استفاده کنید: 33 | 34 | docker run --rm -ti hub.elastico.io/library/debian /bin/bash 35 | 36 | در مقابل اگر بخواهید کانتینری به محض اجرا به پس زمینه برود و همچنان به اجرای دستور ادامه دهد میتوانید از پارامتر `-d` استفاده کنید: 37 | 38 | docker run -d --name my_server hub.elastico.io/library/nginx 39 | 40 | دقت کنید که در این حالت کانتینر شما تا زمانی که اجرای دستور به پایان نرسد یا شما آن را متوقف نکنید در حال اجرا باقی میماند. 41 | 42 | ## دستور ps 43 | 44 | این دستور کانتینرهای در حال اجرا را به شما نشان میدهد: 45 | 46 | docker ps 47 | 48 | همچنین اگر از پارامتر `-a` استفاده کنید میتوانید کانتینرهای متوقف شده را نیز مشاهده کنید. 49 | 50 | ## دستور logs 51 | 52 | برای دیدن خروجی یک کانتینر در حال اجرا میتوانید دستور زیر را بکار ببرید: 53 | 54 | docker logs my_server 55 | 56 | اگر میخواهید منتظر بمانید تا خروجیهای جدید را به محض تولید شدن مشاهده کنید میتوانید از پارامتر `-f` استفاده کنید. 57 | 58 | ## دستور exec 59 | 60 | اگر کانتینری در حال اجرا باشد میتوانید با دستور زیر یک shell در داخل آن اجرا کنید که به شما یک خط فرمان در داخل همان کانتینر برای اجرای دستورات جدید میدهد: 61 | 62 | docker exec -ti my_server /bin/sh 63 | 64 | این کار عموما برای خطایابی در زمان تست استفاده میشود و برای سیستمهای production توصیه نمیشود. 65 | 66 | ## دستور stop 67 | 68 | اگر کانتینری در حال اجرا باشد میتوانید با دستور زیر آن را متوقف کنید: 69 | 70 | docker stop my_server 71 | 72 | دقت کنید که در این حالت اجرای کانتینر متوقف میشود ولی فایلهای آن همچنان روی سیستم باقی میمانند و قابل بازیابی هستند. با استفاده از دستور `docker ps -a` میتوانید کانتینر متوقف شده را نیز مشاهده کنید. 73 | 74 | ## دستور kill 75 | 76 | اگر کانتینری به دستور stop به خوبی پاسخ ندهد، یعنی اجرای آن متوقف نشود، میتوانید از این دستور برای توقف کامل آن استفاده کنید: 77 | 78 | docker kill my_server 79 | 80 | در این حالت نیز همچنان فایلهای کانتینر روی سیستم باقی میمانند. 81 | 82 | اگر مثلا در انتهای روز قصد دارید با یک دستور تمامی کانتینرهای روی سیستمتان را متوقف کنید، میتوانید این فرمان را اجرا کنید: 83 | 84 | docker kill $(docker ps -q) 85 | 86 | 87 | 88 | ## دستور rm 89 | 90 | این دستور فایلهای یک کانتینر متوقف شده را از روی سیستم پاک میکند: 91 | 92 | docker rm my_server 93 | 94 | اگر میخواهید تمامی فایلها را، شامل آنهایی که به صورت volume برای کانتینر تعریف شده اند، حذف کنید از پارامتر `-v` استفاده کنید. 95 | 96 | در مواقعی هم که میخواهید تمامی کانتینرهای متوقف شده را یکباره حذف کنید میتوانید از این دستور استفاده کنید: 97 | 98 | docker rm $(docker ps -a -q) 99 | 100 | ## دستور rmi 101 | 102 | برای حذف یک تصویر (image) داکر که دیگر نیازی به آن ندارید این دستور را اجرا کنید: 103 | 104 | docker rmi my_image_name 105 | 106 | در نهایت اگر روی سیستمتان با کمبود فضای دیسک سخت مواجه شده اید میتوانید با دستور زیر تمامی تصاویری را که به صورت موقت تولید شده اند و معمولا کاربرد دایمی ندارند پاک کنید: 107 | 108 | docker rmi $(docker images -q -f dangling=true) 109 | 110 | اگر به هنگام اجرای کانتینرها با مشکلاتی برای دانلود image ها از Docker Hub مواجه شدید، میتوانید با تنظیم یک mirror به صورتی که در [این گروه](https://groups.google.com/forum/#!topic/software-taak/xRmFWrozRoo) گفته شده، دوباره این کار را امتحان کنید. 111 | -------------------------------------------------------------------------------- /content/blog/what-is-kubernetes-why-need-it.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2017-01-06T14:54:01+04:30" 3 | draft = false 4 | title = "کوبرنتیس چیست (Kubernetes) و چرا به آن نیاز دارید؟" 5 | 6 | +++ 7 | 8 | کوبرنتیس چیست (Kubernetes) و چرا به آن نیاز دارید؟ 9 | === 10 | 11 | [کوبرنتیس](http://kubernetes.io) پیاده سازی جدیدی از بیش از یک دهه تجربه گوگل در اجرای نرم افزارهای سمت سرور در مقیاس بسیار بالاست که به صورت متن باز (open source) در اختیار همه قرار گرفته است. 12 | 13 | این نرم افزار وظیفه اجرا و مدیریت کانتینرها را بر روی گروهی از سرورهای موجود در یک یا چند مرکز داده ها (data center) به عهده دارد. برای درک بهتر این سیستم لازم است قدری با [مفاهیم اولیه کانتینرها مانند داکر](http://elastico.io/blog/docker-basic-concepts.html) آشنایی داشته باشید که میتوانید در همین سایت درباره آن مطالعه کنید. 14 | 15 | کوبرنتیس در واقع نسل سوم از این فنآوریست که در شرکت گوگل از ابتدا به زبان گو (Go) پیاده سازی شده است. دو نسل قبلی آن برگ (Borg) نام داشته که پیاده سازی آن به زبان سی پلاس پلاس بوده است و گوگل همچنان از آن در محیط عملیاتی استفاده میکند. 16 | 17 | در کوبرنتیس یک یا چند کانتینر که به صورت مشترک برنامه ای کاربردی را تشکیل میدهند، به صورت واحدی جداگانه به نام پاد (pod) دسته بندی میشوند تا مدیریت و کشف (discovery) آنها آسانتر شود. 18 | 19 | مزیت کلیدی کوبرنتیس در این است که بدون نیاز به یک تیم بزرگ برای راه اندازی و نگهداری، میتوان آن را در مقیاس وسیع برای اجرای میلیاردها برنامه کاربردی به کار گرفت. از مزایای دیگر آن قابلیت اجرا بر روی بسترهای متفاوت است؛ از سرورهای یک مرکز داده های خصوصی گرفته تا سرویسهای ابری عمومی، یا حتی ترکیبی از هر دو. 20 | 21 | به طور کلی هر شرکتی که یک یا چند سرویس نرم افزاری اجرا میکند به طور بالقوه در مرحله اول به کانتینرها و سپس به سیستمی مانند کوبرنتیس نیاز دارد. [دلیل اصلی نیاز به کانتینرها](http://elastico.io/blog/why-you-need-docker.html) امکان جداسازی برنامه ها (isolation) از یکدیگر در بهترین سطح ممکن است تا فرآیند تولید، تست و در نهایت اجرا بر روی یک زیرساخت مشترک تسهیل شود. 22 | 23 | در مرحله بعد نیاز به کوبرنتیس پیدا میشود تا اجرای این کانتینرها بر روی دسته ای (cluster) از ماشینها را تا حد زیادی اتوماتیک کند. در واقع کوبرنتیس مانند سیستم عاملیست که بر روی تمام سرورهای شما به صورت یکپارچه اجرا میشود و به شما این امکان را میدهد که دیگر نگران هیچ ماشینی به طور خاص نباشید. اگر ظرفیت کافی در زیرساخت شما وجود داشته باشد، این سیستم به راحتی میتواند از دست دادن یک یا چند ماشین را برای شما به گونه ای مدیریت کند که کاربران هیچ تغییری در سرویسهای در حال اجرا بر روی این بستر احساس نکنند. 24 | 25 | این سیستم امکاناتی مانند بررسی سلامت (health check) و تکثیر (replication) برنامه ها را به راحتی بر روی مجموعه سرورهای شما فراهم میکند. از دیگر قابلیتهای آن نیز ویژگیهای مناسب و سطح بالا، مانند کشف سرویسها (service discovery)، توزیع بار (load balancing) و مدیریت پیکربندی (configuration management) است که برای ساخت سیستمهایی با معماری مایکروسرویسی (micro-service architecture) حیاتیست و برای تیمهای شما امکان تولید، تغییر و مقیاس پذیری (scaling) بخشهای مختلف هر سرویس را بر اساس شرایط مورد نیاز فراهم میکند. 26 | 27 | اگر چه بسیاری از نرم افزارها سعی میکنند این قابلیتها را در سطح برنامه کاربردی پیاده کنند ولی تجربه نشان داده است که این کار با وجود صرف زمان و انرژی زیاد در اکثر موارد منجر به یک راه حل شکننده و غیر قابل نگهداری میشود که برای برنامه های کاربردی بعدی باید از نو تکرار شود. کوبرنتیس با انتقال این دغدغه ها به لایه مناسب و آزاد کردن برنامه کاربردی از قید و بند آنها به شما کمک میکند که وقت و انرژی تیم را در جای مناسب و برای تولید ویژگیهای خاص برنامه کاربردی خودتان صرف کنید. 28 | 29 | برای آشنایی بیشتر با این فنآوری میتوانید [ارایه ضبط شده کوبرنتیس](http://taakestan.com/index.php/2012-09-09-10-30-14/55-2016-08-30-kubernetes-docker-conf-tehran) در همایش داکر تهران را بر روی سایت تاک مشاهده کنید. همچنین اگر فکر میکنید شرکت شما به چنین سیستمی نیاز دارد میتوانید به تیم الستیکو ایمیل بزنید (io.elastico AT gmail DOT com) تا در نیازسنجی و راه اندازی آن به شما کمک کنیم. 30 | -------------------------------------------------------------------------------- /content/blog/what-is-registry-repository.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-07-14T14:54:01+04:30" 3 | draft = false 4 | title = "رجیستری (Registry) و مخزن (Repository) داکر چیست؟" 5 | 6 | +++ 7 | 8 | رجیستری (Registry) و مخزن (Repository) داکر چیست؟ 9 | === 10 | 11 | در این نوشته قصد داریم به توضیح مفاهیم رجیستری (Registry) و مخزن (Repository) داکر بپردازیم و همچنین تعدادی از سرویسهای آنلاین ارایه شده برای انتشار تصاویر داکر را معرفی کنیم. 12 | 13 | *جهت اجرای دستورات گفته شده در این مقاله نیاز دارید قبلا داکر را نصب کرده باشید. روش نصب داکر روی [ویندوز](http://elastico.io/blog/install-docker-windows.html) یا [لینوکس CentOS](http://elastico.io/blog/install-docker-centos7.html) را میتوانید در همین سایت مطالعه کنید. همچنین برای یادگیری بهتر این مطلب ممکن است آشنایی با [مفاهیم پایه ای داکر](http://elastico.io/blog/docker-basic-concepts.html) به شما کمک کند.* 14 | 15 | رجیستری (Registry) 16 | --- 17 | رجیستری سرویسی برای ذخیره و نگهداری تصاویر (image) داکر است که بسته به پیاده سازی آن ممکن است به صورت عمومی برای تمام کاربران اینترنت یا به صورت خصوصی تنها در شبکه داخلی یک شرکت قابل دسترسی باشد. هر رجیستری همیشه دارای یک آدرس یکتا مانند docker.io یا hub.elastico.io است و علاوه بر آن ممکن است از طریق یک واسط کاربری آنلاین مشابه ‍[داکر هاب](https://hub.docker.com) یا [الستیکو هاب](https://hub-beta.elastico.io) قابل مدیریت باشد. این واسطهای کاربری در واقع امکان مشاهده تصاویر منتشر شده در یک رجیستری و دسترسی به اطلاعات بیشتر درباره هر تصویر را فراهم میکنند. 18 | 19 | قسمتی از سرویس رجیستری داکر به صورت یک نرم افزار متن باز موجود است که شرکتها میتوانند آن را برای مصارف داخلی خود اجرا کنند. امکان دیگری نیز وجود دارد که خریداری اشتراک این سرویس از شرکتهای ارایه دهنده آن است. مثلا Docker Hub و AWS Container Registry نمونه های معروفی از این سرویس هستند که داکر هاب علاوه بر سرویس خصوصی، اجازه انتشار عمومی تصاویر را به صورت مجانی میدهد. سرویس [الستیکو هاب](https://hub-beta.elastico.io) نیز امکانی مشابه داکر هاب را برای کاربران فراهم میکند. رجیستریهای حرفه ای تر علاوه بر نگهداری تصاویر، ویژگیهایی مانند بررسی امنیت، کنترل دسترسیها و ساخت خودکار تصاویر را هم ارایه میکنند. 20 | 21 | مخزن (Repository) 22 | --- 23 | هر تصویر (image) داکر علاوه بر یک شناسه عددی، بوسیله یک برچسب (tag) نیز قابل شناسایی است. برچسبها در واقع مهمترین راه برای کار با تصاویر داکر هستند و در عمل میتوان به هر تعداد که مورد نیاز است به یک تصویر برچسب اختصاص داد. با اجرای دستور `docker images` میتوانید برچسبهای تصاویری را که در حال حاضر روی سیستم شما وجود دارند مشاهده کنید و با کمک دستور `docker tag` به هر کدام از آنها یک برچسب جدید اختصاص دهید. 24 | 25 | با کمک برچسب مناسب میتوان یک تصویر را به هر رجیستری دلخواه منتقل کرد و در نهایت تمام تصاویری که در رجیستری منتشر شده اند از طریق آدرسهایی با ساختار مشخص در دسترس همه کاربران قرار میگیرند. برای ساده تر کردن مدیریت این تصاویر امکانی فراهم شده است تا مجموعه ای از تصاویر با استفاده از آدرسهایی شبیه به هم تحت عنوان یک مخزن (repository) منتشر شوند. در این حالت بخش ابتدایی آدرسهای این تصاویر که نام مخزن (repository) را مشخص میکند، کاملا یکسان است. به عنوان مثال آدرسهای `hub.elastico.io/library/nginx:stable` و `hub.elastico.io/library/nginx:latest` دو برچسب به نامهای `stable` و `latest‍` از یک مخزن یکسان به نام `lib/nginx` را مشخص میکنند. در این حالت این مخزن در رجیستری الستیکو به آدرس `hub.elastico.io` قرار داده شده است. در این مثال هر یک از این برچسبها معادل یک تصویر جداگانه است که نسخه متفاوتی از نرم افزار Nginx را در بر دارد. 26 | 27 | انتشار تصاویر در رجیستری 28 | --- 29 | تصاویر داکر را میتوانید با استفاده از دستور `docker pull` از رجیستری دریافت و با دستور `docker push` به آن منتقل کنید. این دستورات یک پارامتر ورودی میگیرند که ساختار آن به شکل `repository:tag` یا `registry/repository:tag` است. در حالت اول که آدرس registry مشخص نشده است، داکر به صورت پیش فرض از کتابخانه موجود در رجیستری داکر هاب (Docker Hub) استفاده میکند. 30 | 31 | اگر به عنوان مثال با استفاده از یک `Dockerfile` و دستور `docker build`، مشابه آنچه در مقاله [روش نوشتن داکرفایل]() گفته شده است، یک تصویر داکر با نام `my-first-image` بسازید، میتوانید با اجرای دستورات زیر آن را روی الستیکو هاب منتشر کنید: 32 | 33 | docker tag my-first-image hub.elastico.io/username/my-first-image:test 34 | docker login hub.elastico.io 35 | docker push hub.elastico.io/username/my-first-image:test 36 | 37 | پس از اجرای این دستورات هر کاربر داکر حتی بدون نیاز به `login` میتواند این تصویر را با اجرای دستور `docker pull hub.elastico.io/username/my-first-image:test` از رجیستری الستیکو دانلود کرده و سپس با دستور `docker run` اجرا کند. اما به خاطر داشته باشید که همیشه لازم است قبل از انتشار تصاویر، با اجرای `docker login registry-url` دسترسی لازم به رجیستری مورد نظرتان را کسب کنید. همانطور که بالاتر گفته شد برای سرویس الستیکو هاب این دستور به صورت `docker login hub.elastico.io` خواهد بود. 38 | 39 | در نهایت برای یادگیری روش استفاده از تصاویر و آشنایی بیشتر با دستورات داکر میتوانید مقاله [دستورات پرکاربرد داکر](http://elastico.io/blog/useful-docker-commands.html) را مطالعه کنید. -------------------------------------------------------------------------------- /content/blog/why-you-need-docker.md: -------------------------------------------------------------------------------- 1 | +++ 2 | date = "2016-02-14T16:11:58+05:30" 3 | draft = false 4 | title = " چرا به داکر نیاز دارید؟" 5 | image = "good-to-great.jpg" 6 | +++ 7 | 8 | #### جواب کوتاه: چون میخواهید به عنوان یک کاربر، بتوانید نرم افزارهای گوناگون را خیلی راحت و سریع نصب کنید. همچنین اگر برنامه ساز هستید نیاز دارید برنامه شما توسط کاربران به آسانی قابل اجرا باشد. 9 | 10 | جواب بلند: شیوه قدیمی/فعلی نصب بسیاری از نرم افزارها به این صورت است که شما ابتدا باید بسته (package) نرم افزاری مورد نظرتان را برای سیستم عامل خودتان، مثلا به صورت یک Installer برای ویندوز یا بسته RPM برای RedHat Linux، پیدا کنید و سپس باید مطمئن شوید که پیش نیازهای لازم برای آن را نصب کرده اید و تنها پس از‌ آن است که میتوانید اقدام به نصب کنید. 11 | 12 | البته در بیشتر موارد داستان به همین جا ختم نمی شود. احتمال دارد شما برنامه ای از قبل روی سیستمتان داشته باشید که با این برنامه جدید تداخل کند. محتمل ترین حالت وجود نسخه قدیمی تری از همین برنامه است که نیاز دارید ابتدا آن را از روی سیستم حذف کنید. حذف کردن برنامه ها هم در برخی موارد کار ساده ای نیست و ممکن است حتی پس از حذف یک برنامه نیاز داشته باشید بخشهایی از آن را که بر روی سیستم شما باقی مانده است تک تک پیدا کرده و پاک کنید تا تداخل کاملا برطرف شود. در این قبیل موارد تغییرات در فایلهای سیستمی معمولا بیشترین دردسر را ایجاد میکند چون به نوعی میتوان گفت سیستم شما را آلوده کرده است و برگرداندن آن به وضعیت قبلی کار آسانی نیست. 13 | 14 | مشکل بزرگتر زمانی پیش میاید که برنامه جدید با یکی از برنامه های موجود تداخل میکند ولی شما به هر دوی آنها نیاز دارید. مثالهای معروف آن نصب نسخه های متفاوتی از ابزارهای یک زبان برنامه نویسی است. مثلا برای داشتن نسخه های متفاوتی از ruby به صورت همزمان روی یک سیستم به مشکل برخواهید خورد و نیاز دارید از یک برنامه دیگر به نام rvm استفاده کنید. متاسفانه برای بیشتر بسته های نرم افزاری چنین امکانی اصلا وجود ندارد و شما باید تنها یک نسخه را در هر زمان نصب کنید. 15 | 16 | استفاده از ماشینهای مجازی (Virtual Machine) تا حدی میتواند در حل این مشکلات کمک کند ولی حجیم بودن و سرعت پایین نصب و راه اندازی مانع از همه گیر شدن این روش شده است. همچنین تمام برنامه هایی که روی یک ماشین مجازی خاص نصب میشوند همچنان در معرض این مشکلات قرار دارند. 17 | 18 | داکر به عنوان یک ابزار روزمره این امکان را فراهم میکند که شما بدون نیاز به آلوده کردن سیستم خودتان هر نرم افزاری را که به صورت کانتینر ساخته شده باشد به سرعت و به صورت کاملا مجزا نصب و اجرا کنید. زمانی هم که به این کانتینر احتیاج نداشته باشید با حذف کردن آن تمامی آثار آن از سیستم شما پاک خواهد شد. 19 | 20 | به این ترتیب مثلا شما میتوانید نسخه های متفاوتی از یک محصول را به صورت همزمان نصب و اجرا کنید بدون اینکه آنها از وجود یکدیگر با خبر شوند. سادگی و سرعت استفاده از کانتینرها نیز به مراتب بیشتر از ماشینهای مجازی است و همین امر باعث میشود استفاده از آنها در کار روزمره عملی تر باشد. 21 | 22 | برای آشنایی بیشتر با این تکنولوژی میتوانید [وبینار تاک با موضوع آشنایی مقدماتی با داکر](http://taakestan.com/index.php/2012-09-09-10-30-14/53-docker) را مشاهده کنید و اگر فکر میکنید که همین حالا به داکر نیاز دارید میتوانید [به این ترتیب آن را روی ویندوز نصب کنید](http://elastico.io/blog/install-docker-windows.html). 23 | 24 | به عنوان یک برنامه ساز نیز ایده بسیار خوبیست که برنامه بعدیتان را به صورت یک کانتینر ارایه کنید تا دیگران بتوانند به راحتی آن را نصب و اجرا کنند. مثلا برای [برنامه های تحت وب جاوا میتوانید به این روش آنها را در یک کانتینر قرار دهید](http://elastico.io/blog/jboss-docker-tutorial.html). 25 | -------------------------------------------------------------------------------- /layouts/404.html: -------------------------------------------------------------------------------- 1 | {{ partial "header.html" . }} 2 |
3 |

404

4 |
This page doesn't exist.
5 |
6 | {{ partial "footer.html" . }} 7 | 8 | -------------------------------------------------------------------------------- /layouts/_default/li.html: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /layouts/_default/list.html: -------------------------------------------------------------------------------- 1 | {{ partial "header.html" . }} 2 |
3 |

{{ .Title }}

4 | {{ range .Data.Pages }} 5 |
6 | {{ .Render "li" }} 7 | {{ end }} 8 |
9 | {{ partial "footer.html" . }} 10 | 11 | -------------------------------------------------------------------------------- /layouts/_default/single.html: -------------------------------------------------------------------------------- 1 | {{ partial "header.html" . }} 2 | {{ $baseurl := .Site.BaseURL }} 3 |
4 |
5 | {{ .Date.Format "Jan 2, 2006" }} 6 |
7 |
8 |
9 | {{ .Content }} 10 |
11 |
12 | 13 | 66 |
67 |
68 | {{ with .Site.Params.avatar }}{{ end }} 69 | {{ with .Site.Params.bio }}
{{ . }}
{{ end }} 70 |
71 |
72 | 75 |
76 | {{ partial "footer.html" . }} -------------------------------------------------------------------------------- /layouts/index.html: -------------------------------------------------------------------------------- 1 | {{ partial "header.html" . }} 2 |
3 | {{ range $index, $page := .Paginator.Pages }} 4 | {{ if ne $index 0 }} 5 | {{ end }} 6 | {{ .Render "li" }} 7 | {{ end }} 8 | {{ partial "pagination.html" .Paginator }} 9 |
10 | {{ partial "footer.html" . }} 11 | 12 | -------------------------------------------------------------------------------- /layouts/partials/footer.html: -------------------------------------------------------------------------------- 1 |
2 | 3 |
4 | 10 | 11 |
12 | 13 | 16 | {{ with .Site.Params.ga_api_key }} 17 | 25 | {{ end }} 26 | 27 | 28 | 29 | 30 | -------------------------------------------------------------------------------- /layouts/partials/header.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {{ if ne .URL "/" }}{{ .Title }} · {{ end }}{{ .Site.Title }} 7 | 8 | 9 | 10 | 11 | 12 | {{ if isset .Params "featuredimage" }} 13 | 7 |
8 |
9 | {{ .Content }} 10 |
11 |
12 | 13 | 66 |
67 |
68 | {{ with .Site.Params.avatar }}{{ end }} 69 | {{ with .Site.Params.bio }}
{{ . }}
{{ end }} 70 |
71 |
72 | 75 | 76 | {{ partial "footer.html" . }} -------------------------------------------------------------------------------- /themes/allegiant/layouts/index.html: -------------------------------------------------------------------------------- 1 | {{ partial "header.html" . }} 2 |
3 | {{ range $index, $page := .Paginator.Pages }} 4 | {{ if ne $index 0 }} 5 | {{ end }} 6 | {{ .Render "li" }} 7 | {{ end }} 8 | {{ partial "pagination.html" .Paginator }} 9 |
10 | {{ partial "footer.html" . }} 11 | 12 | -------------------------------------------------------------------------------- /themes/allegiant/layouts/partials/footer.html: -------------------------------------------------------------------------------- 1 |
2 | 3 |
4 | 10 | 11 |
12 | 13 | 16 | {{ with .Site.Params.ga_api_key }} 17 | 25 | {{ end }} 26 | 27 | 28 | 29 | 30 | -------------------------------------------------------------------------------- /themes/allegiant/layouts/partials/header.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | {{ if ne .URL "/" }}{{ .Title }} · {{ end }}{{ .Site.Title }} 7 | 8 | 9 | 10 | 11 | 12 | {{ if isset .Params "featuredimage" }} 13 |