» Bring Your Own RubyĪ long-standing issue with some plugins and third-party distributions packaging Vagrant revolves around Vagrant shipping its own Ruby. A compiled Go plugin's cross-platform capability will ease distribution and usage by simplifying current requirements for complex dependency management. You will be able to port plugins written with the new API across platforms and release them independently of Vagrant’s releases. A plugin SDK will provide common utilities and helpers for plugin development. Plugin authors will be able to create Vagrant plugins in Go or any other language with GRPC support. While the existing Ruby plugin API will continue to be supported, Vagrant will support a new plugin API with the help of the HashiCorp go-plugin library. The update will also resolve issues around Vagrant’s index file growing too big or being too fragile. This improves Vagrant’s resilience to bad changes. Global configuration management helps organize Vagrant’s state and lays the foundation for adding a web-based UI, error checking, and transaction-based interactions. Lost settings can result in unexpected and unintended system modifications. This will fix long-running issues where provider-specific information results in lost configuration settings. A new, server-based approach will allow for management of a global Vagrant configuration, which you can also store in a database. Different users on the same system do not have access to the same configuration. ![]() » Global Configuration ManagementĬurrently, you can reference only your own local configuration of Vagrant. This prevents arbitrary code execution inline in Vagrantfiles. You will also be able to write configuration in HashiCorp Configuration Language (HCL) to limit the potential for mistakes or risk arising from dynamic configuration. In addition to finer control of trusted commands, you will be able to use controls to prevent automatic evaluation of Ruby-based Vagrantfiles. Vagrant 3.0 will enable a privileged service to execute known and trusted commands from Vagrant and its plugins without the need for direct user interaction. Instead, you must confirm a User Account Control (UAC) prompt, which makes it difficult to run Vagrant in a headless context. ![]() On Windows systems, you cannot use a sudoers file. Unfortunately, you need to update this file any time you change the privileged Vagrant commands. You can work around request and acceptance on POSIX platforms using a sudoers file to define each Vagrant command with escalated privileges. Vagrant runs as a user process that requires acceptance from a user to run privileged actions. You will still be able to run Vagrant locally on a desktop machine and use the new security capabilities. This streamlines the collaboration experience offered by the existing Vagrant Share plugin. You will be able to install Vagrant on a resource-intensive machine and interact with it on a thin client, which will allow sharing of one Vagrant environment among multiple team members.Ī new client-server model will facilitate easy sharing of configuration and resources while also giving administrators power over Vagrant’s privileged actions. The new architecture will allow you to run Vagrant on a remote host and secure actions on the machine. You can look forward to many new features, capabilities, and improvements made possible by these updates to Vagrant’s architecture: » Client-Server Architecture While we don't yet have specific timeframes, we will announce our plans for these new versions of Vagrant as they solidify over the next few months. This includes detection for Ruby Vagrantfiles and installation of compatibility helpers to minimize interruptions to user workflow. Vagrant 3.0 will introduce new methods for configuration but retain tooling for continued compatibility of Vagrantfiles. Over the next year, Vagrant 2.3 and 2.4 will not break compatibility promises of Vagrantfiles or plugin interfaces. They’ll also offer a more seamless plugin development experience by improving the portability of plugins and reducing the complexity of package management. The changes we are working on now are designed to allow you to run Vagrant with a client-server architecture, secure it better on different operating systems, and manage its configuration globally. In this post, we’ll discuss how migration to a Go code base will not only support developer environments of the past decade but also new development workflows, environments, and ecosystems. ![]() In pursuing the goal to continue improving Vagrant, we discovered a path that would allow Vagrant to be ported to Go and still support its Ruby-based features. A growing community of developers, operators, designers, and products rely on Vagrant. HashiCorp Vagrant started as a small project to make interacting with virtual machines for local development easy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |