If the development environment is run on the host, is there a fast way to configure these and deploy them to multiple machines? If so, how?
Vagrant does this but as virtual machines, which may be painfully slow.
What are some viable alternatives?
Absolutely, if you are talking about using a resource pool to deploy and configure your VMs (dev VMs).
For the sake of simplicity, I assume your virtual environment is hosted on VMWare.
Here are a few things to start off with
For Automating creation of VMs (deploying from templates, configure networking etc) you can use VMWare's PowerCLI (Powershell cmdlets) - more on this here
If your dev environment is purely Windows then, for configuration management, you can use DSC (free) or if you (your org) can afford go the expensive route of using SCCM
If you have a lot of Linux boxes to configure then, fortunately, you have more than one option - Ansible, Chef, Puppet or SaltStack
Spinning off and configuring these machines on demand entirely depends on your needs. One of the (more common ways) to do is, create a VM template (aka base vm) and then deploy a VM from this template.
This base template is usually a bare-bones OS + some common utils + tools - Once a VM is deployed from the template, you can then use one of the above mentioned CM (Configuration Management) tools to install/configure this VM.
Hope this gives some pointers in the right direction
Related
I'd like to deploy kubernetes on a large physical server (24 cores) and I'm uncertain as to a number of things.
What are the pros and cons of creating virtual machines for the k8s cluster other than running on bare-metal.
I have the following considerations:
Creating vms will allow for work load isolation. New vms for experiments can be created and assigned to devs.
On the other hand, with k8s running on bare metal a new NAMESPACE can be created for each developer for experimentation and they can run their code in it. After all their code should be running in docker containers.
Security:
Having vms would limit the amount of access given to future maintainers, limiting the amount of damage that could be done. While on the other hand the primary task for any future maintainers would be adding/deleting nodes and they would require bare metal access to do that.
Authentication:
At the moment devs would only touch the server when their code runs through the CI pipeline and their running deployments are deployed. But what about viewing logs? Could we setup tiered kubectl authentication to allow devs to only access whatever namespaces have been assigned to them (I believe this should be possible with the k8s namespace authorization plugin).
A number of vms already exist on the server. Would this be an issue?
128 cores and doubts.... That is a lot of cores for a single server.
For kubernetes however this is not relevant:
Kubernetes can use different sized servers and utilize them to the maximum. However if you combine the master server processes and the node/worker processes on a single server, you might create unwanted resource issues. You can manage those with namespaces, as you already mention.
What we do is use continuous integration with namespaces in a single dev/qa kubernetes environment in which changes have their own namespace (So we run many many namespaces) and run full environment deployments in those namespaces. A bunch of shell scripts are used to manage this. This works both with a large server as what you have, as well as it does with smaller (or virtual) boxes. The benefit of virtualization for you could mainly be in splitting the large box in smaller ones so that you can also use it for other purposes then just kubernetes (yes, kubernetes runs except MS Windows, no desktops, no kernel modules for VPN purposes, etc).
I would separate dev and prod in the form of different vms. I once had a webapp inside docker which used too many threads so the docker daemon on the host crashed. It was limited to one host luckily. You can protect this by setting limits, but it's a risk: one mistake in dev could bring down prod as well.
I think the answer is "it depends!" which is not really an answer. Personally, I would split up the machine using VM's and deploy that way. You've got better flexibility as to how much of the server's resources you carve out and you can easily create new environments, then destroy easily.
Even if these vms are really big, I think it's still easier to manage also given that you have existing vm's on the machine.
That said, there's not a technical reason that you can't run a single node server, but you may run into problems with downtime with upgrades (if that's an issue), as well as if that server needs patched or rebooted, then your entire cluster is down.
I would look at your environment needs for HA and uptime, as well as how you are going to deploy VM's (if you go that route), and decide what works the best for you.
Is there an established way to take a Vagrant box and use it as the operating system for a "bare metal" machine, i.e. a normal computer and not a hypervisor, without having to sit through an installation process?
Now I understand the common response will probably be "install an OS regularly and then use a proper configuration management tool like Puppet or Chef" but hear me out. Our IT organization would like to create a base Vagrant box with all security-related protocols and applications enforced. Then a configuration management tool like Puppet could install "useful" applications like databases and web servers on top of it.
This works best when a software developer wants to deploy a new utility to development environments or servers - they can write the Puppet code to install exactly what they want, which can be turned over to IT to run it on top of the validated Vagrant box to create a virtual machine server.
By hosting the Vagrant box internally, we can hide the security details from the developer while they write new Puppet code, they can test their Puppet code on the same environment they will run it on, and it will provision much faster during testing since the box is just downloaded once. Most "production" deployments will stay as Virtual Machines.
In rare circumstances, we may want a real, bare-metal server, not a VM, probably when we get new hardware to run more VMs or if the utility we need is very computationally intensive. It would be nice if the existing Vagrant box could be repurposed so bare-metal and virtual servers were indistinguishable.
EDIT: I found a post on askubuntu (https://askubuntu.com/questions/32499/migrate-from-a-virtual-machine-vm-to-a-physical-system) which seems to do what I want, can anyone verify if such a procedure would work on a Vagrant disk image, if there would be necessary cleanup (like Vagrant ssh keys) or if it could be generalized to non-Ubuntu operating systems (since it uses Live CD)?
A Vagrant box packaged for VirtualBox is essentially a virtual disk with metadata. Most likely it's going to have the VirtualBox tools and drivers installed, which won't do much good on a physical system. Not only that, the drivers for the physical system would need to be installed on the box image.
What you're talking about doing is a good use case for some sort of "ghosting" software that simply copies blocks of data to a physical disk. There's really no advantage to using Vagrant here that I can see.
I've been reading about Vagrant, and I find it quite useful for my development. I am currently managing a series of services (mail, web, LDAP, file sharing, etc.), and often one of these falls and needs a quick backup. Is it possible (and recommended) to use Vagrant for these purposes?
So far I've virtual machines installed like real machines.
I would also like to know about an alternative to Vagrant which would allow me to setup a simple configuration file and put a virtual machine, for example, with Zimbra, and quickly have an alternate mail server, enable RabbitMQ, etc.
Vagrant should be used more like a staging environment to test your infrastructure changes. It should be your test bed for automated infrastructure changes.
The way we use it at my company is like so:
Create VMs for our managed servers in Vagrant.
Create puppet definitions for each server.
Create cucumber tests for each server.
Make infrastructure changes via puppet and add cucumber tests.
Launch our servers to test for failures.
Fix bugs, release and/or back to step 4.
Basically when we're happy with our changes, we'll pull our puppet changes into production to make it happen.
I'd not recommend using vagrant to manage VMs for real production. I'd use something else like razor, virsh, OpenStack or one of the many other vm management systems out there.
This page suggests that the Vagrant push command is meant for deploying to production:
https://www.hashicorp.com/blog/vagrant-push-one-command-to-deploy-any-application/
"Additionally, multiple config.push.define declarations can be in a Vagrantfile to define multiple pushes, perhaps one to staging and one to production, for example."
From my experience, Vagrant mainly used in a development environment.
Vagrant configuration and provisioning options are limited compared to Terraform for example.
If you are working on a cloud based environment, you can use Terraform for infrastructure provisioning.
If your environment is local or your VMs will be hosted on a datacenter, you can use Ansible, chef or puppet for you configuration management and automation.
Hashicorp just published Otto, which is meant to be the Vagrant's successor. It is designed to support deployment environments.
From their Github page:
The key features of Otto are:
Automatic development environments: Otto detects your application
type and builds a development environment tailored specifically for that
application, with zero or minimal configuration. If your application depends
on other services (such as a database), it'll automatically configure and
start those services in your development environment for you.
Built for Microservices: Otto understands dependencies and versioning
and can automatically deploy and configure an application and all
of its dependencies for any environment. An application only needs to
tell Otto its immediate dependencies; dependencies of dependencies are
automatically detected and configured.
Deployment: Otto knows how to deploy applications as well develop
them. Whether your application is a modern microservice, a legacy
monolith, or something in between, Otto can deploy your application to any
environment.
Docker: Otto can use Docker to download and start dependencies
for development to simplify microservices. Applications can be containerized
automatically to make deployments easier without changing the developer
workflow.
Production-hardened tooling: Otto uses production-hardened tooling to
build development environments (Vagrant),
launch servers (Terraform), configure
services (Consul), and more. Otto builds on
tools that powers the world's largest websites.
Otto automatically installs and manages all of this tooling, so you don't
have to.
I had the same question and have been investigating the use of Vagrant push which as per their documentation, as of version 1.7, Vagrant is capable of deploying or "pushing" application code in the same directory as your Vagrantfile to a remote such as an FTP server.
I'm considering having vagrant spin up in a VM for developers, while also giving you the option to deploy your code to a live server for production environments.
As mentioned by #andrerpena, Otto is the successor of Vagrant.
From www.ottoproject.io :
Otto can deploy your application. Users of Vagrant for years have wanted a way to deploy their Vagrant environments to production. Unfortunately, the Vagrantfile doesn't contain enough information to build a proper production environment with industry best practices. An Appfile is made to encode this knowledge, and deployment is a single command away.
At work, we (2 other developers and me) develop all of our code on a single internal machine (via network file sharing). This machine runs our development environment (NGINX, Apache, PHP, MySQL, Memcache, Gearman, etc), which is unruly to get installed on a non Linux environment.
We're getting a few more team members (one remote) and I am looking for a better way to manage a common development environment (our developers currently use Windows, Mac, and Linux).
How does your team create a common development platform? A few things I'm thinking about:
Same setup (a single machine where we write code), but make it external (maybe spin up a cloud server).
Force everyone to use Linux and replicate the environment on thier development machines.
Create a virtual machine that replicates the environment and develop inside a VM.
I'm curious what others are doing... Any thoughts on best practices?
In my experience, I've used virtual machines (VMWare) and it has worked pretty effectively in creating the same environment for large teams with many developers.
What is your preferred development environment ?
Native
WAMP/MAMP/LAMP (Apache, MySQL, PHP) on Windows/MacOS/Linux
Working copy local, SVN/CVS on server
IDE/Editor on the same system (Eclipse, Aptana, Zend...)
Virtual/Native (Server on VM)
LAMP on VirtualBox/VMware
working copy in the VM
IDE/Editor on host, access to the VM with Samba, FTP, SFTP (eventually mapping with tools like WebDrive)
Virtual (VM)
Complete development environment running in a VM (server, tools, IDE)
Host is only used for special tools not available on the OS running in the VM
All have pros and cons.
With BitNami stacks you can run the exact same XAMP environment locally or remotely (and make sure everybody on your team is running the exact same stack). It is free and works on Windows, Linux, Mac.
I like having the SVN repository somewhere on a web server.
It's reasonably secure (using Apache WebDAV), and it gives me a good chance of recovering quickly from any disasters that may befall my main development machine. I have the luxury of control over my own web server, but there are lots of cheap hosts that will do the job at low cost.
As regards VM or no VM:
Advantages of VM - very fast recovery from screwing up your development environment
Ability to try out different versions or upgrades quickly
If you have many systems running the VM host, ability to quickly move the whole environment
Can choose any Host
Disadvantages of VM - performance impact; extra setup complexity.
On balance, I go for "no VM" if all the tools are available on my host system, but I do use VM when I need to run a different OS (the host system is a Mac Pro, so if I need Visual Studio, I do it with Parallels).