The sample code for this post can be found on GitHub.
While we can always install PostgreSQL on our host machine, it's a much cleaner solution to create something like a local virtual machine with Vagrant or a container using Docker. That way, any changes we make to the database and then forget about are not around as soon as we destroy either the container or the virtual machine. It is one more way to tighten that feedback loop we need as developers.
I'll provide an example using Vagrant in this post, though migrating to Docker should be fairly straightforward once you get the steps. Note that the following example is not even remotely secure, and if you use this method for anything but local sandboxing you will almost certainly get a cyber smack across the face at some point in the future.
First, let's set up a simple VagrantFile that defaults to using the IP 192.168.56.111:
Vagrant.configure("2") do |config| config.vm.box = "ubuntu/bionic64" config.vm.provider "virtualbox" do |v| v.memory = 2048 v.cpus = 1 end config.vm.provision :shell, path: "postgres-provision.sh" config.vm.network "private_network", ip: "192.168.56.111" end
In the same directory as the VagrantFile, we're going to need a file called "postgres-provision.sh". We need to:
The following bash script accomplishes that, and also creates a test database called "testdb" as another place to toy around:
#!/bin/bash sudo apt-get update && sudo apt-get -y install postgresql # set the default to listen to all addresses sudo sed -i "/port*/a listen_addresses = '*'" /etc/postgresql/10/main/postgresql.conf # allow any authentication mechanism from any client sudo sed -i "$ a host all all all trust" /etc/postgresql/10/main/pg_hba.conf # create db named testdb sudo su postgres -c "createdb testdb" # restart the service to allow changes to take effect sudo service postgresql restart
If you run
$ vagrant up
You should see your VM go live and be ready to play in your sandbox.