Usually our customers bring their own build infrastructure. For older C++ projects I was deploying a set of 3 virtual servers (Ubuntu 32bit+64bit + Windows). But all this stationary computers are standing in the way if you actually do coding from where and when ever you want. Either you have only small upload, high energy consumption or you family doesn’t like this old boxes in your flat :/
So let’s build in the cloud :) Travis is a number to expensive if you aren’t doing OpenSource only and just want to try things out. I wanted to do something else than Jenkins, so this time it’s about TeamCity, or VPN at first.
The only problem is: nobody likes managing servers. So the main target was that the build server is not really webfacing. It’s running in it’s own VPN. The VPN can be entered by the Laptop and so it’s only necessary to keep SSH and OpenVPN services always up to date, a task much easier than patching proprietary software like TeamCity or Jira.
Here is the setup, currently 3 VMs which are building and testing one Scala Play! Application. They are all hosted on Vultr, with 3x5$ per Month is cheap enough and keeps room to scale a little bit. You can even scale it down to only one node when you run all three services on one machine.
The VMs are all 64bit Ubuntu 14.04 LTS.
- One VPN entry server
- One TeamCity Server
- One TeamCity build agent (can be on demand)
OpenVPN is easier to configure than you usually think of it. You need one server and multiple clients, and a simple Public Key Infrastructure. I used EasyRSA 3. There were however some pitfalls:
- Googling for OpenVPN related stuff got tricky since everyone is using it for private surfing
- You want passwords without a passphrase for your server. Just add
nopassto the certificat generation
- To use a Mac as a client: Tunnelblick is a good choice. For Yosemite, use the current Beta. To get DNS working, try out the different mechanisms offered by Tunnelblick.
topology subneton the server, as this is the better default now.
client-to-clienton the Server so that clients can talk to each other.
ns-cert-type serveron the Clients as this is obsolete, it’s enabled on Ubuntu 14.04 by default but not compatible with the generated keys in EasyRSA3.
remote-cert-tls serveron the Clients to avoid MTM-Attacks.
Remembering IP-Addresses in the VPN is not very convenient. One way to solve it, is to let your own DNS server running, I choosed DNSMasq. However this is still a weak issue on the setup, as it’s very manually.
OpenVPN usually gives out the same IP adress for each client. Client IPs are stored in a file called
/etc/openvpn/ipp.txt. From there you can copy them into the
/etc/hosts/ file and make dnsmasq server as a DNS for them. You can configure it to only listen to the
tun0 interface (OpenVPN) only and push it to your clients via
push "dhcp-option DNS 10.8.0.1"
in the OpenVPN server configuration.
Both are for Ubuntu 14.04 LTS.
Note: This OpenVPN configuration is not suitable for private surfing.