GitHub Actions эсвэл GitLab CI: ижил pipeline 91 секундээр зөржээ

Semaphore-ийн Redmine туршилтад ижил ажлыг 2 vCPU бүхий runner дээр, cache-ийг халаасны дараа үйлчилгээ тус бүрт 10 удаа ажиллуулахад GitHub Actions дунджаар 9 минут 44 секунд, GitLab CI 11 минут 15 секунд зарцуулсан; зөрүү нь 91 секунд. Энэ бол тухайн ажлын хэмжилт бөгөөд өөр репозитор дээр ижил зөрүү гарна гэсэн баталгаа биш.

Код нь GitHub дээр байдаг, үйлчилгээний runner ашиглах баг GitHub Actions-ийн багтсан минут болон нэмэлт хэрэглээний үнийг эхэлж тооцож болно. Код, эрхийн удирдлага, CI/CD нь GitLab дээр төвлөрсөн эсвэл өөрийн runner ажиллуулах шаардлагатай бол GitLab CI-г ижил ажлаар хэмжих нь илүү хэрэгтэй. Сонголтыг нэг job-ийн хурд, сарын төлбөр, runner хүлээх хугацааг хамтад нь харж хийнэ.

Туршилтын зөрүү юуг илэрхийлж байна вэ?

Redmine-ийн Ruby on Rails репозиторт хийсэн ажил нь код татах, хамаарлуудыг суулгах, өгөгдлийн санг бэлтгэх, тестүүдийг ажиллуулах алхамтай байв. Хоёр үйлчилгээ ижил репозитор, үндсэн pipeline логик, runtime болон өгөгдлийн сангийн хувилбар ашигласан ч runner-ийн санах ой адил байгаагүй. Тиймээс хэмжилт нь зөвхөн CI үйлчилгээний програмыг бус, түүнд тохируулсан runner болон ажлын орчны нийлбэр үр дүнг харуулна.

Туршилтад ажлуудыг зэрэгцүүлэн ажиллуулаагүй. Нэг job-той pipeline-ийн хугацаа олон job зэрэг эсвэл дараалан ажилладаг төслийн нийт хугацааг төлөөлөхгүй. Cache урьдчилан бэлэн байсан тул шинэ салбарын эхний ажиллуулалт, хамаарал солигдсон үе эсвэл cache сэргээгүй нөхцөлд зарцуулах хугацааг энэ хэмжилтээр таамаглахад бас хэцүү. Хугацааны зөрүүг үйлчилгээ сонгох дохио гэж үзэж болно, харин сарын төлбөрийг өөрийн ажлын бодит үргэлжлэх хугацаагаар тооцох хэрэгтэй.

Hosted runner-ийн минут ямар үнэтэй вэ?

GitHub Actions-ийн төлбөрийн нөхцөлд GitHub Free-ийн хувийн репозиторт стандарт runner-ийн сарын 2,000 минут, GitHub Team-д 3,000 минут багтдаг бөгөөд 2 цөмтэй Linux x64 runner-ийн нэмэлт хэрэглээ минут тутам 0.006 ам.доллар байна. Нийтийн репозиторт стандарт GitHub-hosted runner ашиглахад минутын төлбөргүй; өөрийн runner дээрх Actions хэрэглээ мөн энэ минутын төлбөрт орохгүй. Харин cache болон artifact-ийн хадгалалт тусдаа хязгаар, тарифтай тул том файл хадгалдаг pipeline-ийн нийт зардал зөвхөн ажилласан минутаар тогтохгүй.

GitLab-ийн үнийн хуудсанд GitLab.com Free-д сарын 400 compute минут, Premium-д 10,000, Ultimate-д 50,000 минут багтдаг; Premium нь хэрэглэгч тутам сард 29 ам.доллар бөгөөд жилээр нэхэмжилдэг. Энэ нь багтсан минутыг харьцуулахдаа төлөвлөгөөний суурь төлбөрийг хамт үзэх ёстой гэсэн үг. Premium-ийг аль хэдийн ашиглаж буй багийн нэмэлт CI зардал, зөвхөн минутын төлөө Premium-д шинээр шилжих багийн нийт зардал хоёр өөр.

GitLab-ийн нэмэлт compute минутын нөхцөлөөр 1,000 минутын багц 10 ам.доллар, худалдан авсан минут 12 сарын хугацаанд эсвэл дуусах хүртэл хүчинтэй бөгөөд автоматаар сунгагдахгүй. GitLab.com-ийн нийтийн төсөлд ч shared runner-ийн минутын хязгаар үйлчилнэ; өөрийн runner дээр зарцуулсан хугацаа уг квотоос хасагдахгүй. Иймээс бага хэмжээний илүү хэрэглээнд бүтэн багц авах үеийн мөнгөн төлбөрийг минут тутмын онолын үнээс ялгах шаардлагатай.

Сард 500, 5,000, 20,000 минутын жишээ

Дараах нь нөхцөлт тооцоо: хувийн репозитортой GitHub Free данс, GitLab.com Free namespace, хоёр талд ижил хэмжээний тооцогдох минут, стандарт Linux runner гэж үзэв. GitLab талд жижиг Linux runner ашиглаж, өмнө нь худалдан авсан минут үлдээгүй гэж тооцлоо. Эдгээр нь ижил тооны build-ийн үнэ биш: нэг build хоёр үйлчилгээнд өөр хугацаанд дуусвал сарын хэрэглэсэн минут ч өөр болно.

• Сард 500 минут хэрэглэвэл GitHub-ийн нэмэлт минутын төлбөр 0 ам.доллар. GitLab-ийн багтсан хэмжээнээс 100 минут илүү тул шинээр нэг багц авахад 10 ам.доллар төлнө; худалдан авсан багцын 900 минут хүчинтэй хугацаандаа үлдэнэ.
• Сард 5,000 минут хэрэглэвэл GitHub-д квотоос давсан 3,000 минутын төлбөр 18 ам.доллар. GitLab-д 4,600 нэмэлт минут хэрэгтэй тул шинээр таван багц авахад 50 ам.доллар төлж, 400 худалдан авсан минут үлдэнэ.
• Сард 20,000 минут хэрэглэвэл GitHub-ийн нэмэлт 18,000 минутын төлбөр 108 ам.доллар. GitLab-д 19,600 нэмэлт минут шаардагдах тул шинээр хорин багц авахад 200 ам.доллар төлж, 400 худалдан авсан минут үлдэнэ.

Энэ тооцоонд хэрэглэгчийн суудал, хадгалалт, татвар, өөрийн runner-ийн машин ба арчилгааны зардал ороогүй. GitLab-д өмнөх худалдан авалтаас минут үлдсэн бол тухайн сард шинээр төлөх дүн багасна. Харин баг аль хэдийн Premium ашигладаг бол түүнд багтсан минутыг Free төлөвлөгөөний нэмэлт багц мэт дахин худалдаж авах шаардлагагүй. Ижил сарын build-ийн тоог харьцуулахдаа эхлээд үйлчилгээ тус бүрт хэмжсэн дундаж хугацаагаар хэрэглээгээ гаргах нь зөв.

Cache, хүлээлт ба тооцогдох хугацаа

Cache бэлэн үед хамаарлуудыг дахин татах, суулгах ажил багасч болно. Харин cache сэргээгүй үед уг алхам нийт хугацаанд илүү жин дарна. Иймээс хурдыг харьцуулахдаа хоосон cache-тай эхний ажиллуулалт болон cache сэргэсэн давталтуудыг тусад нь үзэх хэрэгтэй. Cache-ийн үр дүн нь хадгалж буй өгөгдөл, түүний түлхүүр, хамаарал шинэчлэгдэх давтамжаас шалтгаалдаг тул өөр төслийн халаасан cache-тай хэмжилт таны ажлын хэв маягийг орлохгүй.

GitLab-ийн compute минутын тайлбарт job-ийн ажилласан секундийг runner-ийн өртгийн коэффициентоор үржүүлдэг, created болон pending төлөвийн хугацааг тооцдоггүй, жижиг Linux runner-ийн коэффициент 1 гэж заасан. Зэрэг ажилласан job бүрийн минут нийлдэг учраас pipeline-ийн эхнээс дуустал өнгөрсөн хугацаа төлбөрт тооцогдох нийт минуттай тэнцэх албагүй. Runner хүлээсэн хугацаа хэрэглэгчийн хариу авах хурдыг удаашруулж болох ч GitLab-ийн энэ тооцоонд ажилласан минут болж нэмэгдэхгүй.

Өөрийн runner хэзээ тохирох вэ?

Өөрийн runner ашиглавал hosted runner-ийн минутын төлбөрөөс зайлсхийж болох ч тооцоолох хүчин чадал үнэгүй болохгүй. Машины түрээс эсвэл худалдан авалт, сул зогсолт, сүлжээ, шинэчлэлт, гэмтлийн үед сэргээх ажлыг баг хариуцна. Ачаалал тогтмол, ашиглах дэд бүтэц нь бэлэн багт энэ нь ашигтай байж болно; build хааяа огцом олширдог бол хэрэгцээ гарах үед үйлчилгээний runner ашиглах нь зохион байгуулалтын хувьд амар байж магадгүй.

Репозиторын байршил мөн зардалтай холбоотой. Код болон эрхийн удирдлага GitLab дээр төвлөрсөн баг CI-г өөр үйлчилгээ рүү салгавал нэвтрэх эрх, нууц тохиргоо, үр дүнг кодын өөрчлөлттэй холбох ажлыг нэмж шийдэх шаардлагатай. GitHub дээр төвлөрсөн багт ижил асуудал эсрэг чиглэлд гарна. Энэ нь аль нэг үйлчилгээ үргэлж хурдан гэсэн дүгнэлт биш, харин runner-ийн үнийг одоо ажиллаж буй хөгжүүлэлтийн урсгалтай нь хамт үнэлэх шалтгаан юм.

Өөрийн репозитор дээр хэрхэн харьцуулах вэ?

Шийдвэр гаргах хэмжилтэд нэг commit, ижил тестийн багц, runtime болон өгөгдлийн сангийн ижил хувилбарыг ашигла. Код татах, хамаарал суулгах, тест ажиллуулах, artifact хадгалах алхмуудыг аль болох дүйцүүлж, runner бүрийн CPU ба санах ойг тэмдэглэ. Аль нэг талд нэмэлт шалгалт ажилладаг бол түүнийг нөгөө талд давтах эсвэл хугацааг тусад нь үзүүлэх хэрэгтэй; эс бөгөөс үйлчилгээний ялгаанд өөр ажлын хугацааг хольж тооцно.

1. Хоёр талд cache хоосон үеийн ажлыг эхлээд ажиллуул. Дараа нь cache сэргэсэн хэд хэдэн давталт хийж, dependency суулгалт болон тестийн хугацаа хэрхэн өөрчлөгдсөнийг тэмдэглэ. Давталтуудын медиан болон удаан гарсан үр дүнг хамт үзвэл ганц амжилттай ажиллуулалтад найдахгүй.
2. Job үүссэн, runner дээр эхэлсэн, дууссан цагийг тус тус ав. Ингэснээр хүлээлт, ажилласан хугацаа, pipeline-ийн нийт үргэлжлэх хугацааг ялгана. Олон job-той бол зэрэг ажилласан job бүрийн тооцогдох минутыг нийлүүл.
3. Хэмжсэн хугацаагаа сарын бодит build-ийн тоонд хэрэглэж, багтсан квотыг хассан дараа hosted runner-ийн үнийг бод. Өөрийн runner сонголтод машины сарын өртөг, ашиглалтын хувь, түүнийг арчлах ажлыг нэмээд ижил нөхцөлөөр харьцуул.

Ингэж хэмжихэд хурд, төлбөр хоёр өөр талд давуу гарч болно. Тэгвэл багийн хувьд аль нь чухал болохыг кодын өөрчлөлтөөс тестийн хариу авах хугацаа, сарын нийт зардал, runner-ийг өөрөө ажиллуулах боломжтой нь хамт шийднэ.

Мөн уншаарай:

• n8n эсвэл Make: сарын үнэ биш, алхам тоолох арга нь сонголтыг шийднэ
• ChatGPT Images эсвэл Midjourney: текст ба хэв маяг хоёр өөр ялагчтай