Уморявате ли се някога да си играете с Dockerfile? Dockerfiles и Docker изображения са чудесен начин да опаковате приложението си за многократно използваеми, контейнеризирани внедрявания. Писането и поддържането на Dockerfile обаче не винаги е интуитивно и отнема време, което иначе би могло да се използва за добавяне на функции към вашето приложение. Въведете Cloud Native Buildpacks. Съществуват компилационни пакети, за да обединят всичко, от което се нуждае вашето приложение, за да работи, и да го поставите в изображение на Open Container Initiative (OCI) — не е необходим Dockerfile.
За всички разработчици, които се нуждаят от процес на изграждане на контейнер, който е лесен за използване и ще им спести време и главоболия, Cloud Native Buildpacks може да е решението, което търсят. Интересувате ли се? Ще ти кажа повече.
Какво представляват Cloud Native Buildpacks?
Най-общо казано, buildpack взема код на приложение и го прави изпълним чрез процес на изграждане. И така, Cloud Native Buildpacks вземат изходния код на вашето приложение и го превръщат в изпълняваеми, възпроизводими OCI изображения, изпълнявайки вашите изисквания за сигурност на изображенията, оптимизация на производителността и ред на изграждане на контейнери. Това е като да имате точния Dockerfile, от който се нуждаете — само че не е необходимо да пишете такъв.
Докато повечето разработчици могат да напишат Dockerfile, малцина са експерти в Docker или инфраструктура. Твърде много приложения имат Dockerfiles, които са събрани от кодови фрагменти, намерени в мрежата – често комбинация от Copilot, Stack Overflow и ChatGPT. Грешките в Dockerfile могат да доведат до несигурни и лошо работещи приложения.
Cloud Native Buildpacks поемат това бреме, като автоматично прилагат най-добрите практики за всеки език или рамка. След това строителят може да използва произволен брой buildpacks , като автоматично открива кои buildpacks са необходими и ги прилага за изграждане на приложение. Ето компилационните пакети, които конструкторът на Heroku поддържа в момента:
$ pack builder inspect heroku/builder:24 Inspecting builder: heroku/builder:24 REMOTE: Description: Ubuntu 24.04 AMD64+ARM64 base image with buildpacks for .NET, Go, Java, Node.js, PHP, Python, Ruby & Scala. ... Buildpacks: ID NAME VERSION heroku/deb-packages Heroku .deb Packages 0.0.3 heroku/dotnet Heroku .NET 0.1.10 heroku/go Heroku Go 0.5.2 heroku/gradle Heroku Gradle 6.0.4 heroku/java Heroku Java 6.0.4 heroku/jvm Heroku OpenJDK 6.0.4 heroku/maven Heroku Maven 6.0.4 heroku/nodejs Heroku Node.js 3.4.5 heroku/nodejs-corepack Heroku Node.js Corepack 3.4.5 heroku/nodejs-engine Heroku Node.js Engine 3.4.5 heroku/nodejs-npm-engine Heroku Node.js npm Engine 3.4.5 heroku/nodejs-npm-install Heroku Node.js npm Install 3.4.5 heroku/nodejs-pnpm-engine Heroku Node.js pnpm Engine 3.4.5 heroku/nodejs-pnpm-install Heroku Node.js pnpm install 3.4.5 heroku/nodejs-yarn Heroku Node.js Yarn 3.4.5 heroku/php Heroku PHP 0.2.0 heroku/procfile Heroku Procfile 4.0.0 heroku/python Heroku Python 0.23.0 heroku/ruby Heroku Ruby 5.0.1 heroku/sbt Heroku sbt 6.0.4 heroku/scala Heroku Scala 6.0.4
Други създатели, като тези от Paketo или Google Cloud , също предлагат набор от buildpacks. Като цяло екосистемата Cloud Native Buildpacks расте и узрява, което е вълнуващо за разработчиците!
За тези от вас, които са запознати с Heroku, вече сте се наслаждавали на изживяването на buildpack . С git push heroku main можете да внедрите директно в Heroku, без да е необходим Dockerfile. Cloud Native Buildpacks надграждат изживяването на Heroku buildpack, като вземат това, което някога е било специфично за доставчика внедряване и го превръщат в CNCF стандарт, който може да се използва на всяка облачна платформа.
Накратко, Cloud Native Buildpacks позволяват на разработчиците да:
- Разполагайте приложения по-лесно от всякога
- … по стандартен начин без блокиране
- … като същевременно прилага най-добрите практики за контейнери
- ... и без да карате разработчиците да се занимават с Dockerfiles.
Случаи на употреба
Звучи страхотно, нали? С всички тези предимства, нека да разгледаме някои конкретни случаи, в които можете да се възползвате от използването на Cloud Native Buildpacks.
Всяко място, където обикновено имате нужда от Dockerfile, е възможност да използвате buildpack. Примерите включват:
- Node.js уеб приложение
- Микроуслуга на Python
- Разнородно приложение, което използва множество езици или рамки
- Изграждане на приложения за внедряване в облачни платформи като AWS, Azure и Heroku
Едно нещо, което трябва да се отбележи, е следното: Докато buildpacks са декларативни , Dockerfiles са процедурни . С buildpack вие просто декларирате, че искате дадено приложение да бъде създадено с даден buildpack или buildpack. За разлика от това, Dockerfile изисква да дефинирате командите и реда, в който тези команди се изпълняват, за да създадете вашето приложение. Като такива, buildpacks в момента не предлагат нивото на конфигурируемост, което е налично в Dockerfile, така че може да не отговарят на нуждите на някои по-напреднали случаи на употреба.
Това каза, че няма заключване на доставчика с Cloud Native Buildpacks. Те просто изграждат имидж на OCI. Имате нужда от повече персонализиране и опции от наличните в пакета за изграждане? Просто заменете конструктора във вашия конвейер за изграждане с вашия Dockerfile и стандартна компилация на OCI изображение и сте готови.
Проста инструкция
Нека направим кратък преглед на това как да използвате Cloud Native Buildpacks.
За да започнете с buildpacks като разработчик на приложения, първата ви стъпка трябва да бъде да инсталирате инструмента Pack CLI . Този инструмент ви позволява да създавате приложение с buildpacks. Следвайте инструкциите за инсталиране на вашата операционна система.
Освен това, ако все още го нямате, ще ви е необходим Docker демон за създателя, за да изгради вашето приложение, а вие да стартирате вашето изображение. С тези два инсталирани инструмента сте готови да започнете.
Създайте примерно приложение
С достъп до инструмента pack сте готови да го изпробвате, като създадете примерно приложение. Ще стартирам това в приложение Next.js. Нуждаете се от примерно приложение, за да тествате buildpack? Ето пълна директория с примерни приложения на Next.js. Можете също да изпробвате всяко приложение, което имате под ръка.
След като сте подготвили приложението си, започнете, като видите какъв конструктор предлага инструментът за пакетиране. Във вашата обвивка отворете директорията на приложението си и изпълнете тази команда:
$ pack builder suggest
При моята инсталация на Ubuntu, за моето приложение Next.js инструментът pack предлага следните създатели:
Нека опитаме предложения Heroku buildpack ( heroku/builder:24 ). За да използвате този, изпълнете следната команда:
$ pack build my-app --builder heroku/builder:24
Времето за изграждане ще варира в зависимост от размера на вашето приложение; за мен изграждането на приложението отне 30 секунди. С това изображението ми беше готово. Можем да стартираме изображението със следното:
$ docker run -p 3000:3000 my-app
Резултатът изглежда така:
И това е! Успешно изградихме OCI образ на нашето приложение Next.js — без да използваме Dockerfile.
Допълнителни конфигурации
Ами ако трябва да конфигурирате нещо вътре в buildpack? За това трябва да се позовавате на компилационните пакети, които са избрани от вашия строител. Например за моето приложение Next.js мога да видя в регистрационните файлове, че строителят е избрал два пакета за изграждане: nodejs-engine и nodejs-yarn .
Да кажем, че искам да уточня версията на преждата, използвана от buildpack. Първо, ще отида до nodejs-yarn buildpack Readme , където виждам, че мога да посоча версията на преждата в моя файл package.json с ключ packageManager . Бих модифицирал файла си така, че да изглежда така:
{ "packageManager": "[email protected]" }
Оттам всичко, което трябва да направя, е да стартирам отново pack build my-app --builder heroku/builder:24 .
Заключение
Cloud Native Buildpacks са вълнуващ нов начин за изграждане на изображения на контейнери за нашите приложения. Като премахват необходимостта от Dockerfile, те правят пакетирането и внедряването на нашето приложение по-бързо от всякога. Плюс това, тъй като те изграждат стандартни изображения на контейнери, няма блокиране на доставчика.
Cloud Native Buildpacks са в предварителен преглед на много платформи, което означава, че наборът от функции е лек, но бързо развиващ се. Heroku, който е с отворен код на своите Cloud Native Buildpacks , също ги пренася в своята платформа от следващо поколение . Очаквам с нетърпение да видя как Cloud Native Buildpacks позволяват сигурно и бързо внедряване на приложения в общността на облачните платформи.
