Skip to content

Sean's Blag Posts

Deploying Docker Containers without Leaking Secrets

I maintain a Django application at the company at which I am employed. Initially, changes weren’t very frequent, so logging into the host and running a few commands when the application needed to be updated wasn’t a big deal. However, feature creep has set in and changes to the code base are not only more frequent, but are done by more people. Something had to be done.

Whatever solution I was going to implement had a few requirements:

  1. No secrets should be visible in source control
  2. No secrets should be built into the Docker image (anyone who can inspect it can view said secrets)
  3. All code for the process should be stored in source control
  4. The deployment process should not be limited to being run from my laptop or the application server.

Numbers one and three are problematic together, as it’s very easy to just leave a few files in your .gitignore that contain all of your secrets, but that means that #4 is impossible then. Clearly, many people have done this before, right? I mean, isn’t this what CI/CD and DevOps is all about? So, I took to Google.

The third principal of the Twelve Factor App is that the “app stores config in environment variables.” I was already doing that: setting the environment variables for things like my database password and secret key in the supervisor config. A lot of blog posts recommend setting those environment variables with the ENV command in the Dockerfile, but that violates requirement #2 and possibly #1, depending on the method. So that was right out.

The docker run command supports passing environment variables to the container with the -e flag. This seemed like the place to do it, but the question was how.

Another project I had worked on was doing a proof-of-concept of Ansible Tower. For a multitude of reasons (including very high licensing costs), we went with the open-source upstream, AWX, instead. As I’d been implementing that, I’d become aware of Ansible Vault, the a feature of Ansible that allows keeping sensitive data such as passwords or keys in encrypted form instead of plaintext. As Ansible has modules for Docker, AWX was looking like a great tool to use for deployment.

I started writing a simple playbook:

---
- hosts: appservers
become: yes
become: appuser
vars_files:
- "vars/Production.yml"
tasks:
- name: Clone git repository
git:
repo: ssh://git@git.mycompany.com/myproject.git
dest: /opt/myproject/src
accept_hostkey: yes
version: master
key_file: /opt/myproject/.ssh/id_rsa
force: yes
register: gitpull
- name: Build Docker Image
docker_image:
name: myproject-prod
path: /opt/myproject/src
state: present
force: yes
buildargs:
settingsfile: "{{ settings_file }}"
when: gitpull.changed
register: build
- name: Run the container
docker_container:
name: myproject-prod
image: myproject-prod:latest
published_ports: '8000:8000'
state: started
restart_policy: always
recreate: '{{ "yes" if (build.changed) else "no" }}'
env:
SECRET_KEY: "{{ secretkey }}"
SQL_HOST: "{{ sqlhost }}"
SQL_USERNAME: "{{ sqluser }}"
SQL_PASSWORD: "{{ sqlpassword }}"
BIND_PASSWORD: "{{ bindpassword }}"

I’m doing a number of things here. Most of them should be fairly simple, but I’ll talk about a few of the more interesting things I did. First, I’m only building the container when cloning the git repo reports a change. There’s no need to rebuild the image if it’s going to build the same thing. Second, I’m setting recreate to yes if I did rebuild the image, as I want to run the new container, not keep the old one chugging along. I could have left it statically as yes and set the task to run based on “when” conditions, but there are situations in which I may need to start the container via deployment (like if my host goes down).

You’ll also note that I brought in a vars_file. This file contains definitions of all of the variables you see in the “env” section of the docker_container task and looks something like this:

This was created using the ansible-vault command, like this:

ansible-vault encrypt_string 'super_secret_password' --name 'sqlpassword'

This tool then asks you for the vault password, then spits out the encrypted version of the string.

From there, we can run the playbook like this:

ansible-playbook --ask-vault-pass -K -i prod deploy.yml

After entering our sudo and vault passwords, the application is deployed.

Next time, I’ll talk about turning this into a one-click operation with AWX.

Building a Ruby RPM for armv7hl

We’ve recently decided to supplement the temperature monitoring provided by the UPS units in our IDFs with Raspberry Pis and DHT22s. There’s a nice article on setting them up to pipe data into Zabbix, the monitoring system we use at work, so this is incredibly useful to us.

We use CentOS here, so converting from Raspbian to CentOS wasn’t too tricky, although the Zabbix agent is only available in the un-official, un-QAed armv7hl EPEL repository. Again, nothing too tough here. Not something I’d want on a critical system, perhaps, but if the agent stops working, at least we’ll get alerts. 😉

The problem arose when I went to install Puppet, which we use for long-term configuration maintenance. It turns out that the CentOS 7 OS repository for armv7hl doesn’t include Ruby, which Puppet requires. Now, I’m currently trying to rebuild a Ruby 2.3 RPM on the Raspberry Pi so that I can get Puppet installed. Will post updates here (including a link to the RPM) once I get it figured out.

NuPass Released

NuPass, my user-readable password generator, is now released (currently 0.2.1) and is available on PyPI.

This means that I should get to updating NuPassWeb and its live version, nupass.pw. I’m totally open to pull requests, if you feel like helping out.

Setting up oVirt 4

At work, we’re currently evaluating oVirt as a replacement for our VMware infrastructure. We had evaluated it around 3.5 and found it wanting, but the 4.0 release led us to reevaluate. I found the setup process a little lacking, but once setup correctly, it works delightfully well.

Setting up the First Host

Storage Configuration

Shared storage is required to setup oVirt. This can be an NFS share from your first host, but separate storage is highly recommended. In my setup, I used an NFS share from an illumos box we have laying around. Ensure that the NFS shares for oVirt are owned by 36:36 (vdsm).

For the rest of the post, I will assume that your hosts have at least two NICs: one for management and VM traffic and another for storage traffic.

Installation Process

Grab a copy of the oVirt Node ISO and begin installing it on the first host.

The installation process is very similar to CentOS 7. Configure the hostname and assign an IP address to the first network interface. Assign a root password and don’t bother creating a user.

Once the installation completes, reboot the host.

Hosted Engine Setup

In oVirt parlance, the “Engine” is the component that manages the hosts, much like vCenter or XenCenter. A Hosted Engine is when you run the Engine as a VM.

SSH into the first host and install the latest ovirt-engine-appliance package, which can be found here.

# yum install
http://resources.ovirt.org/pub/ovirt-4.0/rpm/el7/noarch/ovirt-engine-appliance-4.0-20160829.1.el7.centos.noarch.rpm -y

Edit /etc/hosts and add entries for this host, as well as the oVirt Engine we will be setting up. This step is crucial, as name resolution is required to complete the setup and oVirt will drop your current DNS servers when it creates the bridge interface during Hosted Engine setup.

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.100.80 	ovengine ovengine.lab.calnet.us
192.168.100.81	ov01 ov01.lab.calnet.us

Open a web browser and login to the Cockpit page on the oVirt host (https://<<IP_ADDRESS>>:9090/). Login as root and click on the Networking link, then the add VLAN button. Set the Parent Interface as the second NIC, likely enp2s0f1, and the VLAN ID as your SAN. Assign the new VLAN interface an IP address on that VLAN, ignore IPv6 traffic, connect automatically, and enable the interface.

Enable the parent interface (enp2s0f1), as well, but disable IPv4, ignore IPv6, and connect automatically.

Click on the Virtualization tab, then on Hosted Engine, then click the Start button.

Answer the following questions:

  1. Are you sure you want to continue? Yes
  2. Please specify the storage you would like to use: nfs3
  3. Please specify the full shared storage connection path to use: 10.0.101.22:/data00/NFS-shared/ovirt_storage/hosted_engine
  4. Please indicate a nic to set ovirtmgmt bridge on: enp2s0f0
  5. iptables was detected on your computer, do you wish setup to configure it? Yes
  6. Please indicate a pingable gateway IP address: 192.168.100.254
  7. Please specify the device to boot the VM from: disk
  8. Please specify the console type you would like to use to connect to the VM: vnc
  9. Please choose which OVF archive you would like to use: 1
  10. Would you like to use cloud-init to customize the appliance on the first boot? Yes
  11. Would you like to generate on-fly a cloud-init ISO image? Generate
  12. Please provide the FQDN you would like to use for the engine appliance: ovengine.lab.calnet.us
  13. Automatically execute engine-setup on the engine appliance on first boot? Yes
  14. Automatically restart the engine VM as a monitored service after engine-setup? Yes
  15. Please provide the domain name you would like to use for the engine appliance: lab.calnet.us
  16. Enter root password that will be used for the engine appliance: <Same as host>
  17. Confirm root password: <Same as host>
  18. Please specify the CPU type to be used by the VM: <Use default>
  19. Please specify the number of virtual CPUs for the VM: 4
  20. You may specifya unicast MAC address for the VM or accept a randomly generated default: <Use default>
  21. Specify the memory size of the VM in VM: 12722
  22. How should the engine VM network be configured: Static
  23. Please enter the IP address to be used for the engine VM: <The IP address selected previously and added the /etc/hosts>
  24. Please provide a comma-separated list (max 3) of IP addresses of domain name servers for the engine VM: 192.168.100.5,192.168.100.6
  25. Add lines for the appliance itself and for this host to /etc/hosts on the engine VM? <If you’ve added DNS records, you can safely enter No. Else, Yes>
  26. Enter engine admin password: <password>
  27. Confirm engine admin password: <password again>
  28. Enter the name which will be used to identify this host inside the Administrator Portal: ov01
  29. Provide the name of the SMTP server through which we will send notifications: mail.lab.calnet.us
  30. Please provide the TCP port number of the SMTP server: 25
  31. Please provide the email address from which notifications will be sent: ovirt@lab.calnet.us
  32. Please provide a comma-separated list of email addresses which will get notifications: sean@lab.calnet.us
  33. Please confirm installation settings: Yes

Let the process do it’s thing and eagerly await the message “Hosted Engine Setup successfully completed!”.

Next time, we’ll discuss configuring the default datacenter.

Notes on DMing on Roll20

Making Tokens

I use RPTools’ TokenTool (specifically version b27) to create (N)PC tokens from the character’s portrait. The tool is fairly simple:

  1. Extract the zip file and double-click on ‘tokentool-1.0.b27.jar’
    • After a moment, the tool’s window will launch.
  2. Drag-and-drop the character’s portrait onto the black portion of the window.
  3. Size and position the image.
    • Click-and-drag the image to reposition.
    • Use the arrow buttons on the right to size the image. Double-arrows are for large size changes; single-arrows are for smaller changes.
  4. Using the dropdown box, select the ring for the token
    • Personally, I use circles for PCs and hexagons for NPCs, but this is entirely up to you.
  5. Under the file menu, select Save Token and save the new token where you want it.
  6. Upload to Roll20
  7. ???
  8. Profit

Using Tokens in Game

Now that your tokens have been created, you need to use them. Drop them onto the Object/Token layer, click on it, then on the gear to edit it.

  • Ensure that the “Represents Character” box has the right character selected. This is based on character sheets in the journal.
  • The “Name” field will show up in the Turn Tracker and on their nameplate, if you show it. I like to use first names or the name the character is known by here, especially if the character is using an assumed name.
  • Ensure that the dropdown box for “Bar 1” is set to hp. This will automatically populate with current HP / max HP from the character’s sheet.
  • You can add other bars, if desired, but I find them to not be terribly useful.

  • To ensure all players can see the health bar (a good, non-meta way of sharing how messed up a fellow character is at-a-glance), click on the “See” checkbox for Bar 1.
  • Ensure the “Has Sight” checkbox is checked, especially if you plan on using Dynamic Lighting.
  • This is also where you’d set what light the player emits.
    • For a torch, enter 40 in the first box (entirety of light) and 20 in the second box (where the bright light transitions to dim). You should check the “All Players See Light” box, as it’s a torch and that’s how light works.
    • For darkvision, enter the range of their darkvision in the first box (60, usually) and -5 in the second box, so that all of the light is dim. Ensure that “All Players See Light” is unchecked, as no one else has access to that player’s darkvision.
    • For blindness, you cannot just uncheck the Has Sight box, as the player would be able to move through your light obstructions. What you should do, is set the token’s angle of vision to 0 degrees. This way, the player is blind, but is still stopped when they bump into doors or walls.

  • Save the changes to the token.
  • Now, on the edit the character in the journal, select the token, then click on the “Use Selected Token” button. This will make it so that all of the settings you’ve applied to the token will be used whenever the player drops their token onto the map.

Building NPC Character Sheets

Coming Soon

Basic Dynamic Lighting

Coming Soon

Connecting Network Gear to Avocent/Cyclades ACS Console Server

There’s a lot of differing information about what the proper cabling for connecting Cisco/HP/whatever network gear to an ACS console server. I’ve seen everything from straight-through to rollover to a modified version of straight-through. However, Avocent provided the correct version and I’ve verified that it works.

From the Avocent/Emerson Power site:

RJ-45 (Cyclades) to RJ-45 (Sun/Cisco), crossoverRJ-45 RJ-45
Cyclades Sun/Cisco
——– ———
3 TxD ———— RxD 6
6 RxD ———— TxD 3
4 Gnd ——–|— Gnd 4
|— Gnd 5
2 DTR ———— DSR 7
7 DCD ———— DTR 2
1 RTS ———— CTS 8
5 CTS ———— RTS 1

To build this, take a standard TIA-568B straight-through cable and cut of one end. Remake the cut end as follows:

Pin 1 2 3 4 5 6 7 8
Color Brown White/Brown Green Blue White/Orange White/Green Orange White/Blue (optional)

The factory end would go into the console port of the network gear, while your custom end would go into the ACS.

Updating the Firmware on Quanta LB4M Switches

There seems to be a lack of information (that isn’t misinformation) on how to upgrade the firmware on Quanta LB4M switches. Posts abound containing warnings about bricking your switch. Likely, these people attempted some XMODEM transfer that was not needed. All you need is a TFTP server, which can even be running on your local computer.

Grab a copy of the firmware from Jared’s site (or my mirror: 1.1.0.8 / 1.0.2.17). I used lb4m.1.1.0.8.bin as it’s the latest and seems to be the most featureful, although I’m still trying to locate a copy of the release notes for each version.

Make that file available via your TFTP server and ensure that your switch can see your TFTP server (ping should do nicely). I’ll assume that your TFTP server is on 192.168.1.100, so if it isn’t replace that with the IP you’re using. Once your switch can see the TFTP server, it’s time to begin.

The LB4M has two firmware slots: image1 and image2. You’ll need to determine which is currently active, as you cannot download firmware to the active slot.

(Switching) #show bootvar

Image Descriptions

image1 : default image
image2 :

Images currently available on Flash

--------------------------------------------------------------------
unit      image1     image2      current-active         next-active
--------------------------------------------------------------------

  1     1.0.2.14   1.0.2.14              image1              image1

This shows that we need to download the firmware into image2, as image1 is the currently loaded firmware. We do that with the following command:

(Switching) #copy tftp://192.168.1.100/lb4m.1.1.0.8.bin image2

Select ‘y’ at the prompt of “Are you sure you want to start?” and the transfer will begin. It will take a few minutes, but should complete without issue, assuming your TFTP server is reachable and working properly. If all goes well, you’ll see the following:

Verifying CRC of file in Flash File System

File transfer operation completed successfully.

All that’s left is activating the image and rebooting.

(Switching) #boot system image2
Activating image image2...

(Switching) #reload

re2c on EPEL7

I’ve just pushed a build of re2c to epel-testing. This has been asked for in a bugzilla ticket and is required for building openvpn-auth-ldap, which I’ll be working on next.

You can look at the specific build here and, if you test it, please make your comments on its bodhi page.