{"id":76764,"date":"2020-04-04T13:42:24","date_gmt":"2020-04-04T11:42:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee"},"modified":"2020-04-04T13:42:24","modified_gmt":"2020-04-04T11:42:24","slug":"reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","title":{"rendered":"Release of werf 1.1: improvements in the builder today and plans for the future","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Release of werf 1.1: improvements in the builder today and plans for the future\" src=\"\/wp-content\/uploads\/2020\/04\/c7c26e4a0b7bddb90ba087a4db7175dc.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/\">werf<\/a><\/noindex> \u2014 our open-source GitOps CLI utility for building and delivering applications in Kubernetes. As promised, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">the release of version v1.0<\/a><\/noindex> marked the beginning of adding new features to werf and revising conventional approaches. We are now pleased to introduce release v1.1, which is a significant step forward and a foundation for the future. <i>builder<\/i> werf. The version is currently available in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">channel 1.1 ea<\/a><\/noindex>.<\/p>\n<p>The core of the release features a new stages storage architecture and optimization of both builders (for Stapel and Dockerfile). The new storage architecture opens up possibilities for implementing distributed builds across multiple hosts and parallel builds on a single host.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>The optimizations entail eliminating unnecessary computations during the stages signature calculations and modifying the checksum calculation mechanisms to more efficient ones. This optimization reduces the average build time for projects using werf. Even empty builds, where all stages exist in the cache <i>stages-storage<\/i>, are now genuinely fast. In most cases, restarting a build will take less than 1 second! This also applies to the verification procedures for stages during the execution of commands. <code>werf deploy<\/code> and <code>werf run<\/code>.<\/p>\n<p>Additionally, this release introduces a content-based image tagging strategy \u2014 <i>content-based tagging<\/i>, which is now enabled by default and is the only recommended method.<\/p>\n<p>Let\u2019s take a closer look at the key innovations in werf v1.1, while also sharing plans for the future.<\/p>\n<h2>What has changed in werf v1.1?<\/h2>\n<p><\/p>\n<h3>New stage naming format and cache stage selection algorithm<\/h3>\n<p>\nA new rule for stage name generation. Every stage build now generates a unique stage name, consisting of 2 parts: a signature (as it was in v1.0) plus a unique timestamp identifier.<\/p>\n<p>For example, the full stage image name may look like this:<\/p>\n<p><code>werf-stages-storage\/myproject:d2c5ad3d2c9fcd9e57b50edd9cb26c32d156165eb355318cebc3412b-1582656767835<\/code><\/p>\n<p>\u2026 or in general form:<\/p>\n<p><code>werf-stages-storage\/PROJECT:SIGNATURE-TIMESTAMP_MILLISEC<\/code><\/p>\n<p>Here:<\/p>\n<ul>\n<li> <code>SIGNATURE<\/code> \u2014 is the stage signature representing the content identifier of the stage, depending on the Git commit history that led to this content;<\/li>\n<li> <code>TIMESTAMP_MILLISEC<\/code> \u2014 this is a guaranteed unique identifier for the image, generated at the time of building a new image.<\/li>\n<\/ul>\n<p>\nThe cache stage selection algorithm is based on checking the ancestry of Git commits:<\/p>\n<ol>\n<li> Werf calculates the signature of a certain stage.<\/li>\n<li> In <i>stages-storage<\/i> There may be several stages for a given signature. Werf selects all stages that match the signature.<\/li>\n<li> If the current stage is associated with Git (git-archive, a custom stage with Git patches: <code>install<\/code>, <code>beforeSetup<\/code>, <code>setup<\/code>; or git-latest-patch), then werf selects only those stages that are related to a commit that is a parent of the current commit (for which the build is initiated).<\/li>\n<li> From the remaining matching stages, one is chosen \u2014 the oldest by creation date.<\/li>\n<\/ol>\n<p>\nA stage for different Git branches can have the same signature. However, werf will prevent the use of cache associated with different branches, even if the signatures match.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentation<\/a><\/noindex>.<\/p>\n<h3>A new algorithm for creating and saving stages in the stages storage<\/h3>\n<p>\nIf during the stage selection from the cache werf does not find a suitable stage, a process to build a new stage is initiated.<\/p>\n<p>Note that multiple processes (on one or several hosts) may start building the same stage at roughly the same time. Werf uses an optimistic locking algorithm <i>stages-storage<\/i> at the moment of saving the freshly built image in <i>stages-storage<\/i>. Thus, when the new stage build is ready, werf locks <i>stages-storage<\/i> and saves the freshly built image there only if there is no suitable image already existing <i>(by signature and other parameters \u2014 see the new algorithm for stage selection from cache)<\/i>.<\/p>\n<p>The freshly built image will have a unique identifier by <code>TIMESTAMP_MILLISEC<\/code> <i>(see the new stage naming format)<\/i>. If a suitable image is found in <i>stages-storage<\/i> , werf will discard the freshly built image and use the cached image.<\/p>\n<p>In other words: the first process that finishes building the image (the fastest) will have the right to save it in stages-storage (and then this single image will be used for all builds). The slower build process will never block the faster process from saving the current stage build results and moving on to build the next.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/stages_and_images.html#%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0-%D0%B8-%D1%81%D0%BE%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D1%82%D0%B0%D0%B4%D0%B8%D0%B9\">\u2192 Documentation<\/a><\/noindex>.<\/p>\n<h3>Improved Dockerfile builder performance<\/h3>\n<p>\nCurrently, the stage pipeline for the image built from Dockerfile consists of a single stage \u2014 <code>dockerfile<\/code>. When calculating the signature, the checksum of files is considered. <code>context<\/code>, which will be used during assembly. Prior to this improvement, werf recursively processed all files and calculated the checksum by summing the context and mode of each file. Starting from version v1.1, werf can use the calculated checksums stored in the Git repository.<\/p>\n<p>The algorithm is based on <noindex><a rel=\"nofollow\" href=\"https:\/\/git-scm.com\/docs\/git-ls-tree\">git ls-tree<\/a><\/noindex>. The algorithm considers entries in <code>.dockerignore<\/code> and recursively traverses the file tree only when necessary. Thus, we have detached from reading the file system, and the algorithm's dependency on the size of <code>context<\/code> is not significant.<\/p>\n<p>The algorithm also checks untracked files and includes them in the checksum if necessary.<\/p>\n<h3>Performance has improved when importing files<\/h3>\n<p>\nIn werf versions v1.1, a rsync server is used when <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/configuration\/stapel_image\/import_directive.html\">importing files from artifacts and images<\/a><\/noindex>. Previously, importing was conducted in two steps using directory mounting from the host system.<\/p>\n<p>Import performance on macOS is no longer limited by Docker volumes, and imports are performed in the same time as on Linux and Windows.<\/p>\n<h3>Content-based tagging<\/h3>\n<p>\nWerf v1.1 supports so-called content-based image tagging \u2014 <i>content-based tagging<\/i>. The tags of the resulting Docker images depend on the content of these images.<\/p>\n<p>When you run the command <code>werf publish --tags-by-stages-signature<\/code> or <code>Now, if specified, it is changed to<\/code> will tag published images with what is referred to as <b>stage signature<\/b> of the image. Each image is tagged with its own stage signature, which is calculated according to the same rules as the regular signature of each stage individually, but serves as a generic identifier of the image.<\/p>\n<p>The stage signature of the image depends on:<\/p>\n<ol>\n<li> the content of this image;<\/li>\n<li> the history of commits in Git that led to this content.<\/li>\n<\/ol>\n<p>\nIn a Git repository, there are always empty commits that do not alter the content of the image files. For example, commits that only have comments, merge commits, or commits that change files in Git that will not be imported into the image.<\/p>\n<p>Using content-based tagging addresses the issue of unnecessary application pod restarts in Kubernetes due to image name changes, even if the image content has not changed. By the way, this is one of the reasons that hinder storing multiple microservices of a single application in a single Git repository.<\/p>\n<p>Furthermore, content-based tagging is a more reliable tagging method than tagging based on Git branches, because the content of the resulting images is not dependent on the order of execution of pipelines in the CI system for building multiple commits from the same branch.<\/p>\n<p><b>Important<\/b>From this point onward <i>stages-signature<\/i> \u2014 this is <b>the only recommended tagging strategy<\/b>. This will be used by default in the team <code>In the CI system, the tagging strategy is set by the command<\/code> (unless another tagging scheme is explicitly specified).<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/reference\/publish_process.html#%D1%82%D0%B5%D0%B3%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2-%D0%BF%D0%BE-%D1%81%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%BC%D1%83\">\u2192 Documentation<\/a><\/noindex>. A separate publication will also be dedicated to this feature. <b>UPDATED<\/b> (April 3): Article with details <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/495112\/\">published<\/a><\/noindex>.<\/p>\n<h3>Logging Levels<\/h3>\n<p>\nUsers will have the ability to control output, set the logging level, and work with debugging information. Options added <code>--log-quiet<\/code>, <code>--log-verbose<\/code>, <code>--log-debug<\/code>.<\/p>\n<p>By default, the output contains minimal information:<\/p>\n<p><img decoding=\"async\" alt=\"Release of werf 1.1: improvements in the builder today and plans for the future\" src=\"\/wp-content\/uploads\/2020\/04\/58e981b2e0c579ddde817eadc1732874.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nWhen using detailed output (<code>--log-verbose<\/code>) you can track how werf operates:<\/p>\n<p><img decoding=\"async\" alt=\"Release of werf 1.1: improvements in the builder today and plans for the future\" src=\"\/wp-content\/uploads\/2020\/04\/487ed5dfc5df0178f7c09f8da697ceff.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nThe detailed output (<code>--log-debug<\/code>), in addition to werf's debugging information, also contains logs from the libraries used. For example, you can see how the interaction with Docker Registry occurs and log instances where significant time is spent:<\/p>\n<p><img decoding=\"async\" alt=\"Release of werf 1.1: improvements in the builder today and plans for the future\" src=\"\/wp-content\/uploads\/2020\/04\/99c1f3c2ab3803ff11fae1f2d5c9a5af.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Future Plans<\/h2>\n<p>\n<b>Attention!<\/b> The capabilities described below marked <b>v1.1<\/b> will become available in this version, many of them \u2014 soon. Updates will come through auto-updates <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">when using multiwerf<\/a><\/noindex>. These features do not affect the stable part of v1.1 features, their emergence will not require manual user intervention in existing configurations.<\/p>\n<h3>Full support for various implementations of Docker Registry (NEW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Timeline: March<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2199\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nThe goal is for the user to use any implementation without restrictions when using werf. <\/p>\n<p>Currently, we have identified the following set of solutions for which we intend to guarantee full support:<\/p>\n<ul>\n<li> Default (library\/registry)*,<\/li>\n<li> AWS ECR,<\/li>\n<li> Azure*,<\/li>\n<li> Docker Hub,<\/li>\n<li> GCR*,<\/li>\n<li> GitHub Packages,<\/li>\n<li> GitLab Registry*,<\/li>\n<li> Harbor*,<\/li>\n<li> Quay.<\/li>\n<\/ul>\n<p>\nThe solutions marked with an asterisk are currently fully supported by werf. For the others, support exists but with limitations.<\/p>\n<p>Two main issues can be highlighted:<\/p>\n<ul>\n<li> Some solutions do not support deleting tags via the Docker Registry API, which prevents users from using the automatic cleanup implemented in werf. This is true for AWS ECR, Docker Hub, and GitHub Packages.<\/li>\n<li> Some solutions do not support so-called nested repositories (Docker Hub, GitHub Packages, and Quay) or do support them, but the user must create them manually using the UI or API (AWS ECR).<\/li>\n<\/ul>\n<p>\nWe plan to address these and other issues by using the native APIs of the solutions. This task also includes full-cycle testing coverage of werf for each of them.<\/p>\n<h3>Distributed image build (\u2191)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2 v1.1 (the priority for implementing this feature has been increased)<\/i><\/li>\n<li> <i>Timeline: March-April March<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1614\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nCurrently, werf v1.0 and v1.1 can only be used on a single dedicated host for image building and publishing operations and application deployment in Kubernetes.<\/p>\n<p>To enable distributed work in werf, where building and deploying applications in Kubernetes occurs on multiple arbitrary hosts that do not retain their state between builds (temporary runners), werf requires the ability to use Docker Registry as a stage storage.<\/p>\n<p>Previously, when the werf project was still called dapp, this capability existed. However, we encountered several issues that need to be considered in the implementation of this feature in werf.<\/p>\n<p><b>Note<\/b>This capability does not imply running a builder inside Kubernetes pods, as it requires eliminating the dependency on a local Docker server (there is no access to a local Docker server within a Kubernetes pod because the process itself runs in a container, and werf does not and will not support network interaction with the Docker server). Support for operation in Kubernetes will be implemented separately.<\/p>\n<h3>Official support for GitHub Actions (NEW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Timeline: March<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2210\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIncludes werf documentation (sections <i>reference<\/i> and <i>guide<\/i>), as well as the official GitHub Action for working with werf.<\/p>\n<p>Additionally, it will allow werf to operate on ephemeral runners.<\/p>\n<p>The mechanism for user interaction with the CI system will be based on applying labels to pull requests to initiate specific build\/deployment actions for the application.<\/p>\n<h3>Local development and deployment of applications with werf (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Timeline: January-February April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/1940\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nThe main goal is to achieve a single unified config for deploying applications both locally and in production, without complex actions, 'out of the box'.<\/p>\n<p>werf also requires an operational mode that facilitates convenient code editing and instant feedback from the running application for debugging.<\/p>\n<h3>New cleanup algorithm (NEW)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Deadlines: April<\/i><\/li>\n<li> <i><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/issues\/2212\">Issue<\/a><\/noindex><\/i><\/li>\n<\/ul>\n<p>\nIn the current version of werf v1.1, the procedure <code>Cleanup<\/code> does not include cleanup of images for content-based tagging \u2014 these images will accumulate.<\/p>\n<p>Also, in the current versions of werf (v1.0 and v1.1), different cleanup policies are used for images published under tagging schemes: Git branch, Git tag, or Git commit.<\/p>\n<p>A new unified cleanup algorithm for all tagging schemes has been developed based on Git commit history:<\/p>\n<ul>\n<li> Store no more than N1 images related to the last N2 commits for each git HEAD (branches and tags).<\/li>\n<li> Store no more than N1 stage images related to the last N2 commits for each git HEAD (branches and tags).<\/li>\n<li> Store all images that are used in any resources of the Kubernetes cluster (all kube contexts in the configuration file and namespaces are scanned; this behavior can be restricted with specific options).<\/li>\n<li> Store all images that are used in resource configuration manifests saved in Helm releases.<\/li>\n<li> An image can be deleted if it is not associated with any HEAD from git (for instance, because the respective HEAD itself was deleted) and is not used in any manifests in the Kubernetes cluster and in Helm releases.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Parallel image builds (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.1<\/i><\/li>\n<li> <i>Deadlines: January-February April*<\/i><\/li>\n<\/ul>\n<p>\nThe current version of werf builds images and artifacts described in <code>werf.yaml<\/code>, sequentially. It is necessary to parallelize the process of building independent stages of images and artifacts, as well as ensure convenient and informative output.<\/p>\n<p><i>* Note: the deadline has been shifted due to the prioritization of implementing distributed builds, which will add more capabilities for horizontal scaling, as well as using werf with GitHub Actions. Parallel builds are the next step in optimization, providing vertical scalability when building a single project.<\/i><\/p>\n<h3>Transition to Helm 3 (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Deadlines: February-March May*<\/i><\/li>\n<\/ul>\n<p>\nIncludes a transition to a new codebase <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/news\/t\/475722\/\">Helm 3<\/a><\/noindex> and a tested, user-friendly method for migrating existing installations.<\/p>\n<p><i>* Note: transitioning to Helm 3 will not add significant features to werf, as all key features of Helm 3 (3-way merge and the absence of tiller) are already implemented in werf. Moreover, werf has <noindex><a rel=\"nofollow\" href=\"https:\/\/werf.io\/documentation\/reference\/deploy_process\/differences_with_helm.html\">additional capabilities<\/a><\/noindex> beyond those mentioned. However, this transition remains in our plans and will be carried out.<\/i><\/p>\n<h3>Jsonnet for describing Kubernetes configuration (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Timeline: January-February April-May<\/i><\/li>\n<\/ul>\n<p>\nWerf will support configuration description for Kubernetes in Jsonnet format. At the same time, werf will remain compatible with Helm, and there will be an option to choose the description format.<\/p>\n<p>The reason is that Go templates are considered by many to have a high entry threshold, and the readability of code in these templates also suffers.<\/p>\n<p>The possibility of implementing other configuration description systems for Kubernetes (such as Kustomize) is also being considered.<\/p>\n<h3>Working within Kubernetes (\u2193)<\/h3>\n<p><\/p>\n<ul>\n<li> <i>Version: v1.2<\/i><\/li>\n<li> <i>Timeline: April-May May-June<\/i><\/li>\n<\/ul>\n<p>\nGoal: to enable image builds and application delivery using runners in Kubernetes. That is, the building of new images, their publication, cleanup, and deployment can occur directly from Kubernetes pods.<\/p>\n<p>To implement this capability, the ability for distributed image builds is first required <i>(see the previous point)<\/i>.<\/p>\n<p>Support for a builder mode without a Docker server (i.e., Kaniko-like build or build in userspace) is also required.<\/p>\n<p>Werf will support building in Kubernetes not only using Dockerfile but also with its own builder Stapel, featuring incremental rebuilds and Ansible.<\/p>\n<h2>Step towards open development<\/h2>\n<p>\nWe love our community (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/werf_ru\">Telegram<\/a><\/noindex>) and want more people to help make werf better, understand the direction we are moving in, and participate in development.<\/p>\n<p>Recently, it was decided to switch to <noindex><a rel=\"nofollow\" href=\"https:\/\/help.github.com\/en\/github\/managing-your-work-on-github\/about-project-boards\">GitHub project boards<\/a><\/noindex> to open up our team's workflow. You can now see the upcoming plans and current works in the following areas:<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/9\">Documentation and Site<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/7\">Testing<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/6\">Bugs and Bad UX<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\/projects\/5\">1.1<\/a><\/noindex>.<\/li>\n<\/ul>\n<p>\nA significant amount of work has been done on issues:<\/p>\n<ul>\n<li> Outdated ones have been removed.<\/li>\n<li> Existing ones have been standardized to a common format with sufficient detail and thoroughness.<\/li>\n<li> New issues with ideas and suggestions have been added.<\/li>\n<\/ul>\n<p><\/p>\n<h2>How to enable version v1.1<\/h2>\n<p>\nThe version is currently available in <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf#backward-compatibility-promise\">channel 1.1 ea<\/a><\/noindex> (in channels <i>stable<\/i> and <i>rock-solid<\/i> releases will appear as stabilization occurs, however, <i>ea<\/i> it is already stable enough for use, as it has passed through the channels. <i>alpha<\/i> and <i>beta<\/i>). Activated <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">via multiwerf<\/a><\/noindex> as follows:<\/p>\n<pre><code class=\"bash\">source $(multiwerf use 1.1 ea)\nwerf COMMAND ...<\/code><\/pre>\n<p><\/p>\n<h2>Conclusion<\/h2>\n<p>\nThe new architecture of stage storage and optimization of the build system for Stapel and Dockerfile builders opens up opportunities for implementing distributed and parallel builds in werf. These features will soon be available in the same release v1.1 and will become automatically accessible via the auto-update mechanism (for users <noindex><a rel=\"nofollow\" href=\"https:\/\/ru.werf.io\/v1.1\/documentation\/guides\/installation.html#%D1%81%D0%BF%D0%BE%D1%81%D0%BE%D0%B1-1-%D1%80%D0%B5%D0%BA%D0%BE%D0%BC%D0%B5%D0%BD%D0%B4%D1%83%D0%B5%D0%BC%D1%8B%D0%B9-multiwerf\">multiwerf<\/a><\/noindex>). <\/p>\n<p>This release has added a content-based image tagging strategy \u2014 <i>content-based tagging<\/i>, \u2014 which has become the default strategy. The log of main commands has also been redesigned: <code>werf build<\/code>, <code>werf publish<\/code>, <code>werf deploy<\/code>, <code>werf dismiss<\/code>, <code>werf cleanup<\/code>.<\/p>\n<p>The next significant step will be the addition of distributed builds. Since v1.0, distributed builds have become a higher priority than parallel builds because they add more value to werf: vertical scaling of builders and support for ephemeral builders in various CI\/CD systems, as well as the ability to provide official support for GitHub Actions. Therefore, the timeline for implementing parallel builds has been shifted. However, we are working to implement both capabilities as soon as possible.<\/p>\n<p>Stay tuned for updates! And don't forget to visit us at <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/flant\/werf\">GitHub<\/a><\/noindex>, to create an issue, find an existing one and upvote it, create a PR, or just watch the project's progress.<\/p>\n<h2>P.S.<\/h2>\n<p>\nAlso read in our blog:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/481306\/\">Introducing werf 1.0 stable: what does GitOps, status, and plans have to do with it?<\/a><\/noindex>\u00bb<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/460351\/\">werf is our tool for CI\/CD in Kubernetes (overview and video report)<\/a><\/noindex>\u00bb;<\/li>\n<li> Cycle of release notes for new features in werf:\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/476646\/\">3-way merge in werf: deploying to Kubernetes with Helm \"on steroids\"<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/468049\/\">Using werf for deploying complex Helm charts<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465131\/\">Support for monorepo and multirepo in werf and its connection to Docker Registry<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/463613\/\">You can now build Docker images in werf using a regular Dockerfile<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Source: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/493170\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>werf \u2014 \u043d\u0430\u0448\u0430 GitOps CLI-\u0443\u0442\u0438\u043b\u0438\u0442\u0430 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u043a\u043e\u0434\u043e\u043c \u0434\u043b\u044f \u0441\u0431\u043e\u0440\u043a\u0438 \u0438 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u0432 Kubernetes. \u041a\u0430\u043a \u0438 \u043e\u0431\u0435\u0449\u0430\u043b\u0438, \u0432\u044b\u0445\u043e\u0434 \u0432\u0435\u0440\u0441\u0438\u0438 v1.0 \u0437\u043d\u0430\u043c\u0435\u043d\u043e\u0432\u0430\u043b \u043d\u0430\u0447\u0430\u043b\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u0432 werf \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0438 \u043f\u0435\u0440\u0435\u0441\u043c\u043e\u0442\u0440\u0430 \u043f\u0440\u0438\u0432\u044b\u0447\u043d\u044b\u0445 \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u0432. \u0422\u0435\u043f\u0435\u0440\u044c \u043c\u044b \u0440\u0430\u0434\u044b \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0440\u0435\u043b\u0438\u0437 v1.1, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u0448\u0430\u0433\u043e\u043c \u0432 \u0440\u0430\u0437\u0432\u0438\u0442\u0438\u0438 \u0438 \u0437\u0430\u0434\u0435\u043b\u043e\u043c \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0430 werf. \u0412\u0435\u0440\u0441\u0438\u044f \u0434\u043e\u0441\u0442\u0443\u043f\u043d\u0430 \u043d\u0430 \u0434\u0430\u043d\u043d\u044b\u0439 \u043c\u043e\u043c\u0435\u043d\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":76765,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-76764","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"en_US\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-04-04T11:42:24+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-04-04T11:42:24+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47werf 1.1 release: improvements in the builder today and plans for the future | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"en_US","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0435\u043b\u0438\u0437 werf 1.1: \u0443\u043b\u0443\u0447\u0448\u0435\u043d\u0438\u044f \u0432 \u0441\u0431\u043e\u0440\u0449\u0438\u043a\u0435 \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0438 \u043f\u043b\u0430\u043d\u044b \u043d\u0430 \u0431\u0443\u0434\u0443\u0449\u0435\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/reliz-werf-1-1-uluchsheniya-v-sborshhike-segodnya-i-plany-na-budushhee","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-04-04T11:42:24+00:00","article:modified_time":"2020-04-04T11:42:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"76764","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:30:23","updated":"2022-09-28 14:39:02","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/76764","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/comments?post=76764"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/posts\/76764\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media\/76765"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/media?parent=76764"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/categories?post=76764"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/en\/wp-json\/wp\/v2\/tags?post=76764"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}