I’m headed to China soon, and the Great Firewall can present issues. S2I builds on OpenShift 3 generally require internet access (for example, pulling from Github or installing Ruby Gems), so I wanted to see what it would take to go fully disconnected. It’s actually surprisingly easy. For reference, my environment is the same environment as the OpenShift Training repository. I am using KVM and libvirt networking and all three hosts are running on my laptop. My laptop’s effective IP address, as far as my KVM VMs are concerned, is 192.168.133.1
Also, I have pre-pulled all of the required Docker images into my environment, like the training documentation suggests. This means that OpenShift won’t have to pull any builder or other images from the internet, so we can truly operate disconnected
First, an http-accessible git repository is required for using S2I with OpenShift 3 right now. Doing a google search for a simple git HTTP server revealed a post entitled, unsurprisingly, Simple Git HTTP server. In it, the instructions suggest using Ruby’s built in HTTP server, WEBrick. Here’s what Elia says:
git update-server-info # this will prepare your repo to be served ruby -run -ehttpd -- . -p 5000 |
One thing to note – you must run the update-server-info command after every commit in order for webrick to actually serve the latest commit. I figured this out the hard way. On Fedora and as a regular user, you usually want to use a high port for stuff, so I chose a really high port — 32768. I also had to open the firewall. Fedora, by default, uses firewalld. Your mileage may vary:
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m tcp --dport 32768 -m conntrack --ctstate NEW -j ACCEPT |
With the firewall open, the git repo lives at http://192.168.133.1:32768/.git — not too shabby! Next, we need to make the Ruby Gems accessible via HTTP locally as well. Some Google-fu again brings us to something useful. In this case, Run Your Own Gem Server. While the article indicates that you can just run gem server, I found that this produced strange results and I filed bug #1303. I was using RVM in my environment due to some other project work, so, in the end, my gem server syntax looked like:
gem server --port 8808 --dir /home/thoraxe/.rvm/gems/ruby-2.1.2 --no-daemon --debug |
Of course, this is going to serve gems from your computer, which means the gems have to actually be installed there in the first place. In the case of the Sinatra example, you would have to gem install sinatra --version 1.4.6, which would bring in the gem dependencies. Of course, this requires that you have ruby and rubygems, but you already have that, right?
Running the gem server also requires opening a firewall port:
firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p tcp -m tcp --dport 8808 -m conntrack --ctstate NEW -j ACCEPT |
Note again that these firewall changes will not be permanent. You would need the --permanent option to persist these changes. You now have gems accessible at http://192.168.133.1:8808.
At this point you have:
- A git http server running on port 32768
- A gem server running on port 8808
- Open firewall ports
In your OpenShift 3 environment you can now create a new application whose repository is the git HTTP server you set up with Webrick. Again, that’s http://192.168.133.1:32768/.git But, if you just do that, your build will fail if you don’t have internet access. A standard-looking Gemfile probably defines https://rubygems.org in its source. For example, the Sinatra example that OpenShift provides:
source 'https://rubygems.org' gem 'sinatra', '1.4.6' |
Without internet access, we’ll never get to https://rubygems.org. So we can change the Gemfile’s source line to point at our new gem server, which lives at http://192.168.133.1:8808. Feel free to clone the example repository and try it yourself. Remember, once you change the Gemfile you will need to run git update-server-info and then (re)start your Webrick server. Also, be sure you are doing this on the master branch, or you’ll need to point OpenShift at whatever branch you decided to use. This totally tripped me up a few times.
At this point, you should be able to do your build in OpenShift. In your build log you will see something like the following (ellipses indicate truncated lines):
... I0703 19:44:33.264627 1 sti.go:123] Performing source build from http://192.168.133.1:32768/.git ... I0703 19:44:34.010878 1 sti.go:388] ---> Running 'bundle install ' I0703 19:44:34.339680 1 sti.go:388] Fetching source index from http://192.168.133.1:8808/ I0703 19:44:35.019941 1 sti.go:388] Resolving dependencies... I0703 19:44:35.281696 1 sti.go:388] Installing rack (1.6.4) I0703 19:44:35.437759 1 sti.go:388] Installing rack-protection (1.5.3) I0703 19:44:35.617280 1 sti.go:388] Installing tilt (2.0.1) I0703 19:44:35.841344 1 sti.go:388] Installing sinatra (1.4.6) I0703 19:44:35.841381 1 sti.go:388] Using bundler (1.3.5) I0703 19:44:35.841390 1 sti.go:388] Your bundle is complete! I0703 19:44:35.841395 1 sti.go:388] It was installed into ./bundle I0703 19:44:35.862289 1 sti.go:388] ---> Cleaning up unused ruby gems |
And your application should work! Well, assuming all the rest of your OpenShift environment is set up correctly…