I am having some trouble understanding the vagrant workflow from their website.
I had previously been working on a project and had gone through the whole process of changing directory and setting up the vagrant box, etc. I had even run bundle install that installed all of the gems of the forked project I am working on. I configured the web server to work and was even able to go to see the project on my browser through the web server connection.
Later on I had to go get dinner so I did
vagrant destroy
When I returned, in the same directory I ran
vagrant up
Then I did
vagrant ssh
followed by
cd /vagrant
when I get here I run
rails s
and I get the following error:
The program 'rails' is currently not installed. You can install it by typing:
sudo apt-get install rails
Shouldn't running vagrant up remember all of the work I had previously done? Or do I have to restart from scratch and rebuild all of my gems every time? Am I missing something?
vagrant destroy does literally what the command says - destroys started up VM, completely with disc images. Every change (i.e. installation of software, results of running bundle install, etc) is lost, beyond the changes that happened in /vagrant directory.
If you want to just stop the VM without destroying disc images - you should use vagrant halt instead (or just power off VM as you would do with a real server - i.e. by issuing poweroff).
The general workflow for deploying a vagrant-powered VM outlined in documentation is that you distribute Vagrantfile along with your sources that includes provisioning section (config.vm.provision) which does the stuff you've described - installation of additional software not bundled in a box image (i.e. Rails, gems), setting up the databases, etc. It can be implemented in several ways, starting from just running a simple shell script (with sequential commands to execute), up to using high-profile configuration management systems like Chef, Puppet, CFEngine, Ansible, etc.
Temporary break (like going for dinner) generally does not require even halting a VM, less destroying it. Even a full-fledged VM running under VirtualBox / VMware / KVM with a single-user Rails application hardly consumes lots of resources to worry about.
Related
I have learned to use docker as development server (LAMP and MEAN) and now I feel I should take next step, By removing PHP and node binaries from system and use binaries from containers. So on a fresh Solus install, I setup containers for PHP, node, Ruby etc. Solus already recommends using containers for such tasks. But I got stuck on first day.
I installed vs code (Code-oss) on installed extensions (prettier, PHPCS etc) on it, and they need path of installed binaries (path/to/phpcs, path/to/node etc).
I initially set up configuration path as
docker run -it --rm herloct/phpcs phpcs
based on https://gist.github.com/barraq/e7f85262bc7a0af2d8d8884d27b62d2c but using more updated container. It didn't work, So I set it up as alias thinking it would fool VSCode into thinking it is native command, but it didn't work either. I have confirmed that using those command directly from terminal does work, But VSCode PHPIntellisense extension does not want to work.
Any suggestion?
P.S. Any tip to keep container running in background as to avoid container bootup delay everytime I use PHPCS or javac from container? I can keep LAMP server running but everytime I enter terminal tools, it loads up new container to execute command, and then kill container causing delay for bootup and closing.
In case it is still relevant to someone: You might want to create a VS Code development container to use dockerized binaries.
For this to work, a .devcontainer.json is required which could be as simple as:
{
"image": "mcr.microsoft.com/vscode/devcontainers/typescript-node:0-12"
}
I want to use Docker as a development environment. I am familiar with the basic Docker concepts such as containers, images, volumes, etc. I am also reading this article.
I think that there are already images specifically created for RoR development. Could someone recommend me a couple of images to start with?
Suppose that I create a container, mount my
working folder (RoR projects). Besides code writing, there are also command line jobs such as Linux tasks (update, install), Rails specific commands (Rake, migrations....). I may need to install new binaries or new gems, change Ruby version using rbenv. How can I accomplish these tasks under Docker? May I type a command in a console or ssh the container?
I managed to create an ubuntu container and run it as following:
docker run -it -v /Users/me/Documents/Projects:/var/source_files ubuntu
It creates a console for my container. Next I guess I can run commands like gem install, apt-get update and etc. Is this how we should configure our environment?
I cannot find information on how to run, how to maintain, how add/remove gems, etc.
It's really up to you and what you're comfortable the most with. I'm assuming solo development on some kind of libraries rather than full-fledged apps[1].
I, for example, tend to use Makefiles when developing on specific Golang projects and have some separate images I tend to use for different occasions. For example, if I have to test a Python / Node scripts, I simply type play and I get into a silly container with a few dependencies pre-installed:
https://github.com/odino/dev#play
https://github.com/odino/dev/blob/master/play/Dockerfile
In my personal experience, though, I found that shell scripts / aliases work very well across projects, so I tend to have simple aliases that work on most projects. If I were you, for example, I would use a minimalistic approach and alias dev to docker run -ti -v $(pwd):/src $RUBY_IMAGE so that you can then run dev rake test, dev rails server etc etc from any project. Your $RUBY_IMAGE should have a few utilities installed (htop, curl and so on) and you should be good to go.
Again, I must stress on the fact that it really depends what you're comfortable with -- most of the times I'm extremely productive with just a Makefile.
[1] if working on full-fledged apps docker-compose works well for a lot of people and has a very good DX. minikube is a tool I'd recommend you to pick up only if you know how to work with kubernetes. We used docker-compose for a long time but have switched to minikube since a few months as it closely mirrors our production environment, and minikube works better (imho) when you have quite a few services talking to each other.
I'm trying to develop a Rails project without having to install Ruby and all server tools in my Windows local machine. I've created my Docker containers (Ruby and MySQL) and installed the Docker plugin on RubyMine 2016.1, however it seems not very practical for the development daily use, I mean the cycle develop, run, debug, just before deployment to test server.
Am I missing something to make this workflow possible? Or isn't Docker suggested for this step in the development process?
I don't develop under Windows, but here's how I handle this problem under Mac OS X. First off, my Rails project has a Guardfile set up that launches rails (guard-rails gem) and also manages running my tests whenever I make changes (guard-minitest gem). That's important to get fast turnaround time in development.
I launch docker daemonized, mounting a local directory into the docker image, with an exposed port 3000, running a never-ending command.
docker run -d -v {local Rails root}:/home/{railsapp} -p 3000:3000 {image id} tail -f /dev/null
I do this so I can connect to it with an arbitrary number of shells, to do any activities I can only do locally.
Ruby 2.2.5, Rails 5, and a bunch of Unix developer tools (heroku toolbelt, gcc et al.) are installed in the container. I don't set up a separate database container, as I use SQLite3 for development and pg for production (heroku). Eventually when my database use gets more complicated, I'll need to set that up, but until then it works very well to get off the ground.
I point RubyMine to the local rails root. With this, any changes are immediately reflected in the container. In another command line, I spin up ($ is host, # is container):
$ docker exec -it {container id} /bin/bash
# cd /home/{railsapp}
# bundle install
# bundle exec rake db:migrate
# bundle exec guard
bundle install is only when I've made Gemfile changes or the first time.
bundle exec rake db:migrate is only when I've made DB changes or the first time.
At this point I typically have a Rails instance that I can browse to at localhost:3000, and the RubyMine project is 'synchronized' to the Docker image. I then mostly make my changes in RubyMine, ignoring messages about not having various gems installed, etc., and focus on keeping my tests running cleanly as I develop.
For handling a console when I get exceptions, I need to add:
config.web_console.whitelisted_ips = ['172.16.0.0/12', '192.168.0.0/16']
to config/environments/development.rb in order for it to allow a web debug console when exceptions happen in development. (The 192.168/* might not be necessary in all cases, but some folks have run into problems that require it.)
I still can't debug using RubyMine, but I don't miss it anywhere near as much as I thought I would, especially with web consoles being available. Plus it allows me to run all the cool tools completely in the development environment, and not pollute my host system at all.
I spent a day or so trying to get the remote debugger to work, but the core problem appears to be that (the way ruby-debug works) you need to allow the debugging process (in the docker container) to 'reach out' to the host's port to connect and send debugging information. Unfortunately binding ports puts them 'in use', and so you can't create a 'listen only' connection from the host/RubyMine to a specific container port. I believe it's just a limitation of Docker at present, and a change in either the way Docker handles networking, or in the way the ruby-debug-ide command handles transmitting debugging information would help fix it.
The upshot of this approach is that it allows me very fast turnaround time for testing, and equally fast turnaround time for in-browser development. This is optimal for new app development, but might not work as well if you have a large, old, crufty, and less-tested codebase.
Most/all of these capabilities should be present in the Windows version of Docker, as well.
Is Vagrant a good solutions for creating a Rails environment in windows?
I have a powerful Windows 8 64bit desktop. I recently did a project with RoR and fell in love with it. As I found out, installing RoR on windows is just bleh; so I created a dual boot to ubuntu. As a creative developer, I find it rather difficult to get any of the "creative" done in ubuntu because of the lack of my typical creative tools.
I read a bit about a tool called Vagrant; however, I'm still unsure if it meets my requirements: adobe suite, sublime text, git, rails, rails friendly OS(mac?/ubuntu)
Typical duties: edit an image in photoshop(windows), drop it to project assets in VM?
Typical duties: push/pull to git; ssh to VPS server?
Also, I hear you can install mac os in the VM do you think thats a good option? (because I want to try their new OS)
Installing osx in Vagrant is probably possible but it would likely be quite hard, and its not really what vagrant is designed for.
As for your other questions vagrant sounds like the perfect fit.
With Vagrant you could start up an ubuntu vm and get your rails setup going. Then you could just forward a port on your local machine to the vm and load the rails site as if it were running locally on your windows PC. A quick google gets this vagrant box that looks like it might work for you - https://github.com/amaia/rails-starter-box
To work with the site you can just share a folder between the vm and your local machine which will allow you to edit images and code with your windows apps (Photoshop, sublime) so you don't actually need to install these in the ubuntu vm at all, and can pretty much work as normal.
Git is much the same... I prefer to SSH into the vagrant box and use git on the command line in ubuntu but you can just as easily use gitbash or tortoisegit from windows in the repo folder... works just as well.
A good alternative is, https://github.com/fgrehm/ventriloquist
"Ventriloquist combines Vagrant and Docker to give developers the ability to configure portable and disposable development VMs with ease. It lowers the entry barrier of building a sane working environment without the need to learn tools like Puppet or Chef."
I have the following config
Ubuntu server 10.04 running on a VirtualBox VM (RAM and cpu usage are low)
ruby 1.9.3
rails 3.2.12
webrick
If I do any of the things below the system seems to wait for about 15 seconds before executing the command
- rake taks
- rails s
- navigating to a new page in the app
Things I have looked at
- this is before the sprockets section, and does the same with rake, so at the moment I am not looking at things such as dev-tweaks
- I have changed the webrick config.rb to have the line :DoNotReverseLookup => true
- I have host entries for my host machine on the VM. ping is very fast between both machines
- I have tried Thin and experienced the same issue. I haven't tried mongrel but am thinking I will see the same
But still it is excruciatingly slow.
Any thoughts?
Michael
If you're using VirtualBox shared folders (vboxfs), disk I/O is probably the issue.
vboxfs is really slow, and Ruby on Rails does a lot of files operations in development mode (checking if any files changed etc.).
If you're not using Windows, sharing folders with NFS is the way to go.
Check this link:
http://meta.discourse.org/t/shared-folder-performance-on-vagrant/2443/14
I had this issue using VirtualBox shared folders. As soon as I switched to NFS, I couldn't really make a difference between running natively or in the VM. I imagine Rails autoloading in dev mode is the culprit here. See here on how to configure vagrant to use NFS: https://coderwall.com/p/uaohzg
If you can't setup NFS properly (on OSX 10.7 I had to install NFS Manager to make it work), you can always script away and rsync your rails folder every time you modify files locally in your editor. You don't want to run rails on a VirtualBox shared folder.