We implement an applications deployment subsystem for Apache CloudStack. Today CloudStack is an IaaS orchestration product which enables administrators to provision and manage public and private clouds, the reliable solution used by cloud market leaders. Customers use virtual machines to provide various applications on top of deployed IaaS topologies. Modern delivery approaches such as DevOps, CI/CD, IaC evolved as a reflection of customers’ demands on reliable, predictable, fast and reproducible applications deployments and lifecycle management. In Bitworks we think that IaaS orchestration systems should move toward those customers’ demands by implementing such applications management subsystems.
Recent Posts
GitLab CI artifacts usage via the DEB-package build and publishing example
GitLab CI provides a convenient mechanism for storing build artifacts in GitLab. An artifact is any file that a developer wants to store for a long time after a build completes successfully. This mechanism can be used to store distributions and various build logs. Artifacts are easy-to-use. In this article, using the example of publishing a built DEB-package that is downloadable from GitLab we will show how artifacts storing is implemented.
GitLab CI artifacts are not always convenient to use. Sometimes you may need to enable FTP, SFTP, publishing to Nexus or other artifacts management systems. However, often it is just enough to have a storage that enables the access to build results.
Private unmanaged overlay L2 networks for CloudStack using KVM and VXLAN
On September 5, 2018, we published the first release of the new CloudStack extension, which is designed to automatically deploy unmanaged private LANs for accounts and CloudStack projects. The extension is only for use with clouds running under the KVM hypervisor. After installation, each virtual machine in the account receives an additional VirtIO network card, which belongs to a private network accessible only to machines created within the account.
Atlas of global Apache CloudStack configuration variables, defined at the system level
Not all parameters are described in the article, but only those that you usually need to change when configuring new CloudStack clouds. The parameters for the system are applied after reload of each CloudStack Management server.
CloudStack version: 4.11.1
The parameters described in the article can be configured at: Global Settings
Atlas of Apache CloudStack global configuration variables, defined at the KVM host level
Not all parameters are described in the article, but only those that you usually need to change when configuring new CloudStack clouds that use the KVM hypervisor. The parameters for the KVM host are applied when configuring the host and after each reload of the cloudstack-agent.
CloudStack version: 4.11.1
You can change the settings in the configuration file on the virtualization node: /etc/cloudstack/agent/agent.properties
Many parameters are described in the documentation Apache CloudStack. A full list of parameters with comments can be found in Git-repository CloudStack. Because not all parameters are documented, you can also find some of them in the source code. The parameters described below are recommended to be specified after the successful addition of the host to the cloud, but before the provisioning of virtual machines.