Скриптээс эхлээд өөрсдийн платформ руу: бид CIAN дээр хэрхэн автоматжуулсан хөгжүүлэлт хийсэн

RIT 2019 үзэсгэлэнд манай хамтрагч Александр Коротков хийсэн тайлан CIAN дахь хөгжлийг автоматжуулах талаар: амьдрал, ажлыг хялбарчлахын тулд бид өөрийн Integro платформыг ашигладаг. Энэ нь даалгаврын амьдралын мөчлөгийг хянаж, хөгжүүлэгчдийг ердийн үйлдлээс чөлөөлж, үйлдвэрлэлийн алдааны тоог эрс багасгадаг. Энэ нийтлэлд бид Александрын тайланг нөхөж, энгийн скриптээс хэрхэн нээлттэй эхийн бүтээгдэхүүнийг өөрсдийн платформоор дамжуулан нэгтгэх, мөн автоматжуулалтын тусдаа баг юу хийдэг талаар танд хэлэх болно.
 

Тэг түвшин

"Тэг түвшин гэж байдаггүй, би тийм зүйлийг мэдэхгүй"
"Кунг-фу панда" киноны мастер Шифу

CIAN-ийн автоматжуулалт нь компанийг үүсгэн байгуулагдсанаас хойш 14 жилийн дараа эхэлсэн. Тухайн үед хөгжүүлэлтийн багт 35 хүн байсан. Итгэхэд хэцүү, тийм үү? Мэдээжийн хэрэг, автоматжуулалт ямар нэг хэлбэрээр байсан боловч 2015 онд тасралтгүй нэгтгэх, код хүргэх тусдаа чиглэл бий болсон. 

Тэр үед бид Linux/Windows серверүүд дээр байрлуулсан Python, C# болон PHP-ийн асар том цул байсан. Энэ мангасыг байрлуулахын тулд бид гараар ажиллуулдаг скриптүүдтэй байсан. Мөн салаа мөчрүүдийг нэгтгэх, согогийг засах, "барилга угсралтын ажилд өөр багц ажил" хийх үед зөрчилдөөн, зовлон зүдгүүрийг авчирсан цул угсралт байсан. Хялбаршуулсан үйл явц нь дараах байдлаар харагдаж байв.

Бид үүнд сэтгэл хангалуун бус байсан бөгөөд бид давтагдах боломжтой, автоматжуулсан, удирдах боломжтой бүтээх, байршуулах үйл явцыг бий болгохыг хүссэн. Үүний тулд бидэнд CI/CD систем хэрэгтэй байсан бөгөөд бид Teamcity-ийн үнэгүй хувилбар болон Женкинсийн үнэгүй хувилбаруудын аль нэгийг нь сонгосон, учир нь бид тэдэнтэй хамтран ажиллаж, функцүүдийн хувьд хоёуланд нь тохирсон. Бид Teamcity-г илүү сүүлийн үеийн бүтээгдэхүүн болгон сонгосон. Тэр үед бид микро үйлчилгээний архитектурыг хараахан ашиглаж амжаагүй байсан бөгөөд олон тооны даалгавар, төслүүдийг хүлээж байгаагүй.

Бид өөрсдийнхөө тогтолцооны тухай ойлголттой болсон

Teamcity-ийг хэрэгжүүлснээр гарын авлагын ажлын зөвхөн нэг хэсгийг устгасан: татах хүсэлтийг бий болгох, Jira дахь статусаар асуудлыг сурталчлах, гаргах асуудлуудыг сонгох явдал хэвээр байна. Teamcity систем үүнийг даван туулахаа больсон. Цаашид автоматжуулалт хийх замыг сонгох шаардлагатай байв. Бид Teamcity дахь скриптүүдтэй ажиллах эсвэл гуравдагч талын автоматжуулалтын системд шилжих сонголтуудыг авч үзсэн. Гэвч эцэст нь бид зөвхөн өөрсдийн шийдлээр хангаж чадах хамгийн дээд уян хатан байдал хэрэгтэй гэж шийдсэн. Integro нэртэй дотоод автоматжуулалтын системийн анхны хувилбар ингэж гарч ирэв.

Teamcity нь бүтээх, байршуулах үйл явцыг эхлүүлэх түвшинд автоматжуулалттай холбоотой байдаг бол Integro нь хөгжүүлэлтийн процессуудыг дээд түвшний автоматжуулахад анхаарлаа хандуулдаг. Bitbucket дахь холбогдох эх кодын боловсруулалттай Jira дахь асуудлыг нэгтгэх шаардлагатай байв. Энэ үе шатанд Integro нь өөр өөр төрлийн даалгавартай ажиллах өөрийн гэсэн ажлын урсгалтай болж эхэлсэн. 

Бизнесийн үйл явцын автоматжуулалт нэмэгдсэнтэй холбоотойгоор Teamcity дахь төсөл, гүйлтийн тоо нэмэгдсэн. Тиймээс шинэ асуудал гарч ирэв: нэг үнэгүй Teamcity инстанц хангалтгүй байсан (3 агент, 100 төсөл), бид өөр нэг жишээ нэмсэн (3 агент, 100 төсөл), дараа нь өөр. Үүний үр дүнд бид удирдахад хэцүү байсан хэд хэдэн кластерын системтэй болсон.

Дөрөв дэх инстанцын тухай асуулт гарч ирэхэд бид 4 инстанцыг дэмжих нийт зардал ямар ч хязгаарт багтахаа больсон тул бид цаашид ингэж амьдрах боломжгүй гэдгээ ойлгосон. Төлбөртэй Teamcity худалдаж авах эсвэл үнэгүй Женкинс сонгох тухай асуулт гарч ирэв. Бид инстанцууд болон автоматжуулалтын төлөвлөгөөнүүд дээр тооцоо хийж, Женкинс дээр амьдрахаар шийдсэн. Хэдэн долоо хоногийн дараа бид Женкинс рүү шилжиж, Teamcity-ийн олон тохиолдлыг хадгалахтай холбоотой толгойн өвчинг арилгасан. Тиймээс бид Integro-г хөгжүүлж, Женкинсийг өөрсдөдөө зориулж тохируулахад анхаарлаа төвлөрүүлж чадсан.

Суурь автоматжуулалтын өсөлт (татах хүсэлтийг автоматаар үүсгэх, Кодын хамрах хүрээг цуглуулах, нийтлэх болон бусад шалгалтууд хэлбэрээр) гар аргаар гаргахаас аль болох татгалзаж, энэ ажлыг роботуудад өгөх хүсэл эрмэлзэлтэй байна. Нэмж дурдахад компани нь бие биенээсээ тусад нь байнга гаргахыг шаарддаг компани дотроо микро үйлчилгээ рүү шилжиж эхэлсэн. Ингэж бид аажмаар өөрсдийн бичил үйлчилгээнүүдээ автоматаар гаргахад хүрсэн (одоогоор бид үйл явцын нарийн төвөгтэй байдлаас шалтгаалан цул хэсгийг гараар гаргаж байна). Гэхдээ ихэвчлэн тохиолддог шиг шинэ төвөгтэй байдал үүссэн. 

Бид туршилтыг автоматжуулдаг

Хувилбарын автоматжуулалтын ачаар туршилтын зарим үе шатыг алгассантай холбоотойгоор хөгжүүлэлтийн процесс хурдассан. Энэ нь түр зуурын чанар алдагдахад хүргэсэн. Энэ нь өчүүхэн мэт сонсогдож байгаа ч хэвлэлтийг түргэсгэхийн зэрэгцээ бүтээгдэхүүн боловсруулах арга зүйг өөрчлөх шаардлагатай болсон. Туршилтыг автоматжуулах, гаргасан код, алдааны хувьд хөгжүүлэгчийн хувийн хариуцлагыг (энд бид "толгойд байгаа санааг хүлээн зөвшөөрөх" тухай ярьж байна, мөнгөн торгуулийн тухай ярьж байна), түүнчлэн шийдвэр гаргах талаар бодох шаардлагатай байв. автомат байршуулалтаар дамжуулан даалгаврыг гаргах / гаргахгүй байх. 

Чанарын асуудлуудыг арилгахын тулд бид хоёр чухал шийдвэрт хүрсэн: бид канарын туршилт хийж эхэлсэн бөгөөд алдааны дэвсгэрийн автомат хяналтыг түүний илүүдэлд автоматаар хариу үйлдэл үзүүлдэг. Эхний шийдэл нь кодыг үйлдвэрлэлд бүрэн нэвтрүүлэхээс өмнө илэрхий алдааг олох боломжийг олгосон бол хоёр дахь шийдэл нь үйлдвэрлэлийн асуудалд хариу өгөх хугацааг багасгасан. Мэдээжийн хэрэг алдаа гардаг, гэхдээ бид ихэнх цаг хугацаа, хүчин чармайлтаа алдаагаа засахад бус харин багасгахад зарцуулдаг. 

Автоматжуулалтын баг

Бид одоогоор 130 хөгжүүлэгчийн ажилтантай бөгөөд бид үргэлжлүүлэн ажиллаж байна ургах. Тасралтгүй нэгтгэх, код хүргэх баг (цаашид Байршуулах, нэгтгэх буюу DI баг гэх) нь 7 хүний ​​бүрэлдэхүүнтэй бөгөөд Integro автоматжуулалтын платформ болон DevOps хөгжүүлэх 2 чиглэлээр ажилладаг. 

DevOps нь CIAN сайтын Dev/Beta орчин буюу Integro орчныг хариуцдаг бөгөөд хөгжүүлэгчдэд асуудлыг шийдвэрлэхэд тусалдаг бөгөөд орчныг масштабжуулах шинэ арга барилыг боловсруулдаг. Integro хөгжлийн чиглэл нь Integro өөрөө болон холбогдох үйлчилгээ, жишээлбэл, Jenkins, Jira, Confluence-д зориулсан залгаасууд, мөн хөгжүүлэлтийн багуудад зориулсан туслах хэрэгслүүд, програмуудыг боловсруулдаг. 

DI баг нь архитектур, номын сан, хөгжлийн арга барилыг дотооддоо хөгжүүлдэг Платформ багтай хамтран ажилладаг. Үүний зэрэгцээ CIAN-ийн аль ч хөгжүүлэгч автоматжуулалтад хувь нэмрээ оруулах боломжтой, жишээлбэл, багийн хэрэгцээнд нийцүүлэн бичил автоматжуулалт хийх эсвэл автоматжуулалтыг хэрхэн илүү сайн болгох талаар гайхалтай санаагаа хуваалцах боломжтой.

CIAN дахь автоматжуулалтын давхаргын бялуу

Автоматжуулалттай холбоотой бүх системийг хэд хэдэн давхаргад хувааж болно.

1. Гадаад системүүд (Jira, Bitbucket гэх мэт). Хөгжлийн багууд тэдэнтэй хамтран ажилладаг.
2. Integro платформ. Ихэнх тохиолдолд хөгжүүлэгчид үүнтэй шууд ажилладаггүй, гэхдээ энэ нь бүх автоматжуулалтыг ажиллуулдаг.
3. Хүргэлт, зохион байгуулалт, нээлтийн үйлчилгээ (жишээлбэл, Jeknins, Consul, Nomad). Тэдгээрийн тусламжтайгаар бид серверүүд дээр код байрлуулж, үйлчилгээнүүд хоорондоо ажиллахыг баталгаажуулдаг.
4. Физик давхарга (сервер, үйлдлийн систем, холбогдох програм хангамж). Манай код энэ түвшинд ажилладаг. Энэ нь физик сервер эсвэл виртуал сервер (LXC, KVM, Docker) байж болно.

Энэхүү үзэл баримтлалд үндэслэн бид DI багийн хүрээнд хариуцах хэсгүүдийг хуваадаг. Эхний хоёр түвшин нь Integro хөгжлийн чиглэлийн хариуцлагын хүрээнд, сүүлийн хоёр түвшин нь DevOps-ийн хариуцлагын хүрээнд аль хэдийн орсон байна. Энэхүү тусгаарлалт нь бид бие биетэйгээ ойр дотно, байнга мэдлэг, туршлага солилцдог тул ажилдаа анхаарлаа төвлөрүүлэх боломжийг олгодог бөгөөд харилцан үйлчлэлд саад болохгүй.

Интегро

Integro дээр анхаарлаа хандуулж, технологийн стекээс эхэлцгээе:

• CentOS 7
• Docker + Nomad + Consul + Vault
• Java 11 (хуучин Integro цул Java 8 дээр үлдэх болно)
• Spring Boot 2.X + Spring Cloud Config
• PostgreSql 11
• Rabbit MQ 
• Apache Ignite
• Камунда (суулгасан)
• Графана + Графит + Прометей + Жэйгер + ЭЛК
• Вэб UI: React (CSR) + MobX
• SSO: Түлхүүрийн нөмрөг

Бид Integro-ийн анхны хувилбарын цул хэлбэрээр өвлөн авсан хэдий ч микро үйлчилгээний хөгжлийн зарчмыг баримталдаг. Микро үйлчилгээ бүр өөрийн гэсэн Docker контейнерт ажилладаг бөгөөд үйлчилгээнүүд нь HTTP хүсэлт болон RabbitMQ мессежээр дамжуулан хоорондоо холбогддог. Бичил үйлчилгээнүүд нь Консулаар дамжуулан бие биенээ олж, түүнд хүсэлт гаргаж, SSO (Keycloak, OAuth 2/OpenID Connect)-ээр дамжуулан зөвшөөрөл өгдөг.

Бодит жишээ болгон дараах алхмуудаас бүрдэх Женкинстэй харилцах талаар бодож үзээрэй.

1. Ажлын урсгалын удирдлагын микро үйлчилгээ (цаашид Урсгалын бичил үйлчилгээ гэх) нь Женкинс дэх бүтээцийг ажиллуулахыг хүсч байна. Үүний тулд тэрээр Консулыг ашиглан Женкинстэй (цаашид Женкинсийн микро үйлчилгээ гэх) нэгтгэх микро үйлчилгээний IP: PORT-ийг хайж, түүнд Женкинс дэх бүтээцийг эхлүүлэх асинхрон хүсэлт илгээдэг.
2. Хүсэлтийг хүлээн авсны дараа Женкинсийн микро үйлчилгээ нь ажлын ID-г үүсгэж, хариу өгөх бөгөөд дараа нь ажлын үр дүнг тодорхойлоход ашиглаж болно. Үүний зэрэгцээ энэ нь REST API дуудлагаар дамжуулан Женкинс дэх бүтээцийг идэвхжүүлдэг.
3. Женкинс бүтээх ажлыг гүйцэтгэж, дууссаны дараа гүйцэтгэлийн үр дүнгийн хамт Женкинсийн микро үйлчилгээ рүү вэб дэгээ илгээдэг.
4. Женкинсийн микро үйлчилгээ нь вэб дэгээг хүлээн авсны дараа хүсэлтийг боловсруулж дууссан тухай мессежийг үүсгэж, гүйцэтгэлийн үр дүнг түүнд хавсаргана. Үүсгэсэн мессежийг RabbitMQ дараалал руу илгээдэг.
5. RabbitMQ-ээр дамжуулан нийтэлсэн мессеж нь Flow микро үйлчилгээнд хүрдэг бөгөөд энэ нь хүсэлт болон хүлээн авсан мессежийн ажлын ID-г тааруулж даалгавраа боловсруулсны үр дүнгийн талаар мэдэж авдаг.

Одоо бид 30 орчим микро үйлчилгээтэй бөгөөд тэдгээрийг хэд хэдэн бүлэгт хувааж болно.

1. Тохиргооны удирдлага.
2. Мэдээлэл ба хэрэглэгчидтэй харилцах (элч, шуудан).
3. Эх кодтой ажиллах.
4. Байршуулах хэрэгслүүдтэй (женкинс, номад, консул гэх мэт) нэгтгэх.
5. Хяналт (хувилбар, алдаа гэх мэт).
6. Вэб хэрэгслүүд (туршилтын орчинг удирдах, статистик мэдээлэл цуглуулах гэх мэт UI).
7. Даалгавар хянагч болон ижил төстэй системүүдтэй нэгтгэх.
8. Төрөл бүрийн даалгаварт зориулсан ажлын урсгалын удирдлага.

Ажлын урсгалын даалгавар

Integro нь ажлын амьдралын мөчлөгтэй холбоотой үйл ажиллагааг автоматжуулдаг. Хялбарчилсан хэллэгээр бол даалгаврын амьдралын мөчлөгийг Жира дахь ажлын урсгал гэж ойлгох болно. Бидний хөгжүүлэлтийн процессууд нь төсөл, даалгаврын төрөл, тодорхой даалгаварт сонгосон сонголтуудаас хамааран ажлын урсгалын хэд хэдэн хувилбартай байдаг. 

Бидний хамгийн их ашигладаг ажлын урсгалыг харцгаая:

Диаграммд араа нь шилжилтийг Integro автоматаар дууддаг бол хүний ​​дүрс нь шилжилтийг хүн гараар дууддаг болохыг харуулж байна. Энэ ажлын урсгалд даалгавар авч болох хэд хэдэн замыг харцгаая.

Канарын сорилгүйгээр DEV+BETA дээр бүрэн гарын авлагын туршилт (ихэвчлэн бид цул материалыг ингэж гаргадаг):

Бусад шилжилтийн хослолууд байж болно. Заримдаа асуудал гарах замыг Жира дахь сонголтоор сонгож болно.

Даалгаврын хөдөлгөөн

Даалгавар "DEV Testing + Canary Tests" ажлын урсгалаар дамжих үед хийгдэх үндсэн алхмуудыг харцгаая.

1. Хөгжүүлэгч эсвэл РМ нь даалгаврыг үүсгэдэг.

2. Хөгжүүлэгч нь даалгаврыг ажилд авна. Дууссаны дараа IN REVIEW төлөв рүү шилжинэ.

3. Жира нь Jira бичил үйлчилгээ рүү Webhook илгээдэг (Жиратай нэгтгэх үүрэгтэй).

4. Jira бичил үйлчилгээ нь ажлын урсгалыг эхлүүлэхийн тулд Flow үйлчилгээнд (ажил гүйцэтгэх дотоод ажлын урсгалыг хариуцдаг) хүсэлт илгээдэг.

5. Flow үйлчилгээний дотор:

• Шүүмжлэгчдийг даалгаварт хуваарилдаг (Хэрэглэгчдийн талаарх бүх зүйлийг мэддэг микро үйлчилгээ + Жира микро үйлчилгээ).
• Source microservice-ээр дамжуулан (энэ нь хадгалах газар, салбаруудын талаар мэддэг боловч кодтой ажилладаггүй) манай асуудлын нэг салбарыг агуулсан репозиторуудыг хайлт хийдэг (хайлтыг хялбарчлахын тулд салбарын нэр асуудалтай давхцаж байна) Жира дахь тоо). Ихэнх тохиолдолд даалгавар нь нэг агуулахад зөвхөн нэг салбартай байдаг бөгөөд энэ нь байршуулах дарааллын удирдлагыг хялбарчилж, репозиторуудын хоорондын холболтыг бууруулдаг.
• Олдсон салбар бүрийн хувьд дараах үйлдлүүдийн дарааллыг гүйцэтгэнэ.

  i) Мастер салбарыг шинэчилж байна (кодтой ажиллах Git microservice).
  ii) Салбар нь хөгжүүлэгчийн өөрчлөлтөөс хаагдсан (Bitbucket microservice).
  iii) Энэ салбарт татах хүсэлтийг үүсгэсэн (Bitbucket microservice).
  iv) Шинэ татах хүсэлтийн тухай мессежийг хөгжүүлэгчийн чат руу илгээдэг (Мэдэгдэлтэй ажиллахын тулд микро үйлчилгээнд мэдэгдэх).
  v) DEV (Женкинстэй ажиллахад зориулсан Женкинсийн микросервис) дээр бүтээх, турших, байрлуулах ажлыг эхлүүлсэн.
  vi) Хэрэв өмнөх бүх алхмууд амжилттай хийгдсэн бол Integro нь Татаж авах хүсэлтэд (Bitbucket microservice) Зөвшөөрөхөө оруулна.

• Integro нь томилогдсон хянагчдаас татах хүсэлтийн дагуу Батлагдахыг хүлээж байна.
• Шаардлагатай бүх зөвшөөрлийг хүлээн авмагц (автоматжуулсан тестүүд эерэгээр тэнцсэн) Integro даалгаврыг Dev (Jira microservice) тестийн статус руу шилжүүлдэг.

6. Тестчид даалгаврыг шалгана. Хэрэв ямар ч асуудал гараагүй бол ажлыг "Бэлтгэлд бэлэн" төлөв рүү шилжүүлнэ.

7. Integro нь даалгаврыг гаргахад бэлэн болсныг "харж", түүнийг канарын горимд байрлуулж эхэлнэ (Женкинс микросервис). Суллах бэлэн байдал нь багц дүрмээр тодорхойлогддог. Жишээлбэл, даалгавар нь шаардлагатай төлөвт байгаа, бусад даалгаврууд дээр түгжээ байхгүй, одоогоор энэ микро үйлчилгээний идэвхтэй байршуулалт байхгүй байна гэх мэт.

8. Даалгаврыг Canary статус руу шилжүүлсэн (Jira microservice).

9. Женкинс Канарын горимд (ихэвчлэн 1-3 тохиолдол) Nomad-ээр дамжуулан байршуулах ажлыг эхлүүлж, байршуулалтын талаар хувилбарын хяналтын үйлчилгээнд (DeployWatch microservice) мэдэгдэнэ.

10. DeployWatch бичил үйлчилгээ нь алдааны дэвсгэрийг цуглуулж, шаардлагатай бол түүнд хариу үйлдэл үзүүлдэг. Хэрэв алдааны дэвсгэр нь хэтэрсэн бол (арын нормыг автоматаар тооцдог) хөгжүүлэгчид Notify микросервисээр дамжуулан мэдэгдэнэ. Хэрэв 5 минутын дараа хөгжүүлэгч хариу өгөөгүй бол (Буцах эсвэл Байх дээр дарна уу) канарын тохиолдлуудыг автоматаар буцаах ажиллагааг эхлүүлнэ. Хэрэв арын дэвсгэрийг хэтрүүлээгүй бол хөгжүүлэгч нь үйлдвэрлэлийн даалгаврыг гараар эхлүүлэх ёстой (UI дээрх товчлуур дээр дарж). Хэрэв 60 минутын дотор хөгжүүлэгч үйлдвэрлэлд байршуулалтыг эхлүүлээгүй бол аюулгүй байдлын үүднээс канарын инстанцуудыг мөн буцаах болно.

11. Үйлдвэрлэлд байршуулалтыг эхлүүлсний дараа:

• Даалгаврыг Үйлдвэрлэлийн статус руу шилжүүлсэн (Jira microservice).
• Jenkins бичил үйлчилгээ нь байршуулах процессыг эхлүүлж, DeployWatch бичил үйлчилгээнд байршуулалтын талаар мэдэгдэнэ.
• DeployWatch бичил үйлчилгээ нь Үйлдвэрлэл дээрх бүх контейнерууд шинэчлэгдсэн эсэхийг шалгадаг (бүгд шинэчлэгдээгүй тохиолдол байсан).
• Notify бичил үйлчилгээгээр дамжуулан байршуулалтын үр дүнгийн талаарх мэдэгдлийг Үйлдвэрлэл рүү илгээдэг.

12. Хэрэв микро үйлчилгээний буруу үйлдэл илэрсэн бол хөгжүүлэгчид 30 минутын хугацаанд Үйлдвэрлэлээс даалгаврыг буцааж эхлэх боломжтой. Энэ хугацааны дараа даалгавар автоматаар мастерт (Git microservice) нэгтгэгдэнэ.

13. Мастерт амжилттай нэгтгэсний дараа даалгаврын статус Хаалттай (Jira microservice) болж өөрчлөгдөнө.

Диаграм нь бүрэн нарийвчилсан дүр эсгэдэггүй (бодит байдал дээр илүү олон алхамууд байдаг), гэхдээ энэ нь процесст нэгтгэх түвшинг үнэлэх боломжийг олгодог. Бид энэ схемийг хамгийн тохиромжтой гэж үзэхгүй байгаа бөгөөд автоматаар гаргах, байршуулах дэмжлэгийн үйл явцыг сайжруулж байна.

Дараа нь юу юм

Бид автоматжуулалтыг хөгжүүлэх томоохон төлөвлөгөөтэй байгаа, тухайлбал, цул гаралтын үед гар ажиллагаатай үйлдлүүдийг арилгах, автоматаар байршуулах үед хяналтыг сайжруулах, хөгжүүлэгчидтэй харилцах харилцааг сайжруулах.

Гэхдээ одоохондоо энд зогсооё. Бид автоматжуулалтын тоймд олон сэдвийг өнгөцхөн авч үзсэн, заримыг нь огт хөндөөгүй тул асуултанд хариулахад таатай байх болно. Бид юуг нарийвчлан тусгах талаар санал хүлээж байна, сэтгэгдэл дээр бичээрэй.

Эх сурвалж: www.habr.com