<p>In order to send emails from a VM you need a mail server. Often you can use
a public, corproate, or cloud mail server, but sometimes you might need to
deploy your own locally.</p>
<p>This guide covers how to configure Postfix as a local send-only mail service on
a dedicated Ubuntu VM.</p>
<hr>
<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#create-a-send-only-mail-server-with-postfix">Create a send-only mail server with Postfix</a>
<ul>
<li><a href="#find-your-external-ip-address">Find your external IP address</a></li>
<li><a href="#set-your-hostname-to-an-fqdn-in-etchosts">Set your hostname to an FQDN in /etc/hosts</a></li>
<li><a href="#install-postfix">Install Postfix</a></li>
<li><a href="#configure-postfix">Configure Postfix</a></li>
<li><a href="#send-a-test-email-from-the-command-line">Send a test email from the command-line</a></li>
</ul>
</li>
<li><a href="#troubleshooting">Troubleshooting</a>
<ul>
<li><a href="#check-for--remove-mail-stuck-in-the-queue">Check for &#x26; remove mail stuck in the queue</a>
<ul>
<li><a href="#outlook-is-blocking-your-emails">Outlook is blocking your emails</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#other-references">Other References</a></li>
</ul>
<h1 id="create-a-send-only-mail-server-with-postfix">Create a send-only mail server with Postfix</h1>
<h2 id="find-your-external-ip-address">Find your external IP address</h2>
<p>Many VMs use NAT to accesss the internet. Their <code>ifconfig</code> output won't match
the actual internet IP that the emails will send from.</p>
<p>To check your external IP address, execute:</p>
<pre><code class="language-bash">dig +short myip.opendns.com @resolver1.opendns.com
</code></pre>
<p>Below, the output of this command will be used as <code>&#x3C;ext_ip></code></p>
<p>If you have a static public IP address you can use it as <code>&#x3C;ext_ip></code></p>
<h2 id="set-your-hostname-to-an-fqdn-in-etchosts">Set your hostname to an FQDN in /etc/hosts</h2>
<p>This step is only required if you don't already have a local DNS server or
internet routed static IP with a valid FQDN.</p>
<p>Lets say that your mail will come from a server named alerts.example.com.
Set the hosts file like this:</p>
<p><code>vi /etc/hosts</code></p>
<pre><code class="language-text">127.0.0.1 alerts.example.com
&#x3C;ext_ip>  alerts.example.com
</code></pre>
<h2 id="install-postfix">Install Postfix</h2>
<p>This is the software that manages your mail queue and handles SMTP.</p>
<pre><code class="language-bash">apt-get install -y postfix mailutils
</code></pre>
<p>If it asks you which type of server to install, select Internet Site.
Give it an FQDN when prompted. If you will be sending emails from
<a href="mailto:noreply@alerts.example.com">noreply@alerts.example.com</a>, enter <code>alerts.example.com</code>.</p>
<h2 id="configure-postfix">Configure Postfix</h2>
<p>Here's a configuration that's worked for me.
Be sure to change the <code>myhostname</code> field.</p>
<p><code>vi /etc/postfix/main.cf</code></p>
<pre><code class="language-ini">myhostname = alerts.example.com

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, 63ec22ec9fc1, localhost.localdomain, , localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = loopback-only
inet_protocols = all
</code></pre>
<p>Once configured, restart Postfix:</p>
<pre><code class="language-bash">systemctl restart postfix
</code></pre>
<h2 id="send-a-test-email-from-the-command-line">Send a test email from the command-line</h2>
<p>Pipe some stdout to the <a href="https://linux.die.net/man/1/mail">mail</a> command.
This will be used as the body of the email.</p>
<pre><code class="language-bash">echo "Test alert please ignore" | mail \
  -a "FROM:noreply@alerts.example.com" \
  -s "Test alert" kyle@example.com
</code></pre>
<hr>
<h1 id="troubleshooting">Troubleshooting</h1>
<p>Often emails don't go through. There are lots of reasons that can happen.</p>
<h2 id="check-for--remove-mail-stuck-in-the-queue">Check for &#x26; remove mail stuck in the queue</h2>
<p>Show the mail queue. It might tell you the error if the email is there.</p>
<pre><code class="language-bash">mailq
</code></pre>
<p>If you've got a scheduled job that is adding emails, it can fill the queue up
and make you look like a spammer. Some mail servers will rate limit a sender,
especially if they haven't set up mechanisms by which they can be trusted.</p>
<p>To remove items from the mail queue by ID, run</p>
<pre><code class="language-bash"># If you don't pass &#x3C;ID> it will delete the all.
postsuper -d &#x3C;ID>
</code></pre>
<h3 id="outlook-is-blocking-your-emails">Outlook is blocking your emails</h3>
<p>If you get a 500 error from outlook.*, it could need a connector or a rule
exception for the filter. I haven't tested the connector.</p>
<ul>
<li><a href="https://docs.sophos.com/central/Customer/help/en-us/central/Customer/tasks/bypassingexchange.html">Disable the spam filter</a></li>
<li><a href="https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail">Use a connector (not tested)</a></li>
</ul>
<h1 id="other-references">Other References</h1>
<ul>
<li><a href="https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-postfix-as-a-send-only-smtp-server-on-ubuntu-16-04">Postfix install guide from Digital Ocean</a></li>
<li><a href="https://hostadvice.com/how-to/how-to-setup-postfix-as-send-only-mail-server-on-an-ubuntu-18-04-dedicated-server-or-vps/">Postfix setup guide from hostadvice.com</a></li>
<li><a href="http://www.postfix.org/BASIC_CONFIGURATION_README.html">Basic Postfix config referece</a></li>
<li><a href="http://www.postfix.org/postconf.5.html">Detailed Postfix config docs</a></li>
<li><a href="https://www.cyberciti.biz/faq/how-to-find-my-public-ip-address-from-command-line-on-a-linux/">Whats My IP from Curl</a></li>
<li><a href="https://tecadmin.net/ways-to-send-email-from-linux-command-line/">5 ways to send email from cli</a></li>
<li><a href="https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy">DigitalOcean DKIM guide</a></li>
</ul>


<p>This guide installs OpenStack on a single metal server.</p>
<p>To install OpenStack, I use <a href="https://github.com/openstack/kolla-ansible">Kolla-Ansible</a>,
an open source Ansible project that deploys Kolla OpenStack images.</p>
<p>OpenStack <a href="https://www.openstack.org/software/rocky/">Rocky</a> will be installed,
configured with a
<a href="https://docs.openstack.org/ocata/networking-guide/intro-os-networking.html#intro-os-networking-provider">VLAN provider network</a>
for overcloud networking, and include the following OpenStack APIs:</p>
<ul>
<li>Keystone</li>
<li>Cinder</li>
<li>Nova</li>
<li>Glance</li>
<li>Neutron</li>
<li>Heat</li>
<li>Magnum</li>
</ul>
<hr>
<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#environment">Environment</a></li>
<li><a href="#update--prepare-system">Update &#x26; Prepare System</a></li>
<li><a href="#configure-networking">Configure Networking</a></li>
<li><a href="#enable-vlans-for-neutron">Enable VLANs for Neutron</a></li>
<li><a href="#globals-file">Globals file</a></li>
<li><a href="#install-openstack-using-kolla-ansible">Install OpenStack using Kolla-Ansible</a></li>
<li><a href="#overcloud-cluster-configuration">Overcloud Cluster Configuration</a></li>
<li><a href="#create-a-test-vm">Create a test VM</a></li>
</ul>
<h1 id="environment">Environment</h1>
<p>This was the hardware used while writing this guide. It's neither the minimum
nor recommended hardware setup for any sort of cloud.</p>
<p><strong>Hardware:</strong></p>
<p>Intel NUC with two drives, one interface, 32G RAM, running Ubuntu 18.04.</p>
<p><strong>Drive Labels:</strong></p>
<ul>
<li>Boot drive: <code>/dev/nvme0n1</code></li>
<li>Cinder LVM backup: <code>dev/sda</code></li>
</ul>
<p><strong>Networking</strong></p>
<ul>
<li>Physical interface <code>eno1</code></li>
<li>VLAN subinterface <code>vlan.2@eno1</code></li>
<li>Host IP: <code>10.254.2.2</code></li>
<li>Cloud VIP: <code>10.254.2.254</code></li>
</ul>
<hr>
<h1 id="update--prepare-system">Update &#x26; Prepare System</h1>
<p>Configure the VG for cinder and install Kolla-Ansible</p>
<pre><code class="language-bash"># Update and install deps
apt-get update &#x26;&#x26; apt-get upgrade -y
apt-get -y install python python-pip
pip install \
  ansible \
  python-openstackclient \
  python-neutronclient \
  python-magnumclient

# Create VG for cinder LVM
pvcreate /dev/sda
vgcreate cinder-volumes /dev/sda

# Install Kolla-Ansible
cd ~
git clone https://github.com/openstack/kolla-ansible.git
cd ~/kolla-ansible
git checkout stable/rocky
pip install .

# Deploy initial KA config files
mkdir -p /etc/kolla/config
cp ~/kolla-ansible/etc/kolla/passwords.yml /etc/kolla/
cp ~/kolla-ansible/ansible/inventory/all-in-one /etc/kolla/inventory
kolla-genpwd
</code></pre>
<h1 id="configure-networking">Configure Networking</h1>
<p>The Intel NUC only has one Ethernet port, but Kolla-Ansible requires two ports.
One port is for the APIs, and another can't have any addresses on it as it ends
up being controlled by OpenVSwitch and Neutron.</p>
<p>To get around this, I use VLAN subinterfaces. This works well, but it does
require that you add a layer 3 route from the overcloud subnet to the
undercloud API network the guests need to connect to the host.</p>
<p>OVS creates a bridge bound to the physical port, where the VLAN modules
work alongside it. The only drawback is you can't use those VLANs in the
overcloud.</p>
<p><code>vi /etc/netplan/01-netcfg.yaml</code></p>
<pre><code class="language-text">network:
  version: 2
  renderer: networkd
  ethernets:
      eno1:
        dhcp4: false
        dhcp6: false
  vlans:
    vlan.2:
      id: 2
      link: eno1
      addresses: [ 10.254.2.2/24 ]
      gateway4: 10.254.2.1
      nameservers:
        addresses: ["8.8.8.8", "8.8.4.4"]
</code></pre>
<p>Apply the changes. This might kick you.</p>
<pre><code class="language-bash">netplan try
</code></pre>
<h1 id="enable-vlans-for-neutron">Enable VLANs for Neutron</h1>
<p>Create this config file to enable VLAN support</p>
<pre><code class="language-bash">mkdir -p /etc/kolla/config/neutron
</code></pre>
<p><code>vi /etc/kolla/config/neutron/ml2_conf.ini</code></p>
<pre><code class="language-ini">[ml2_type_vlan]
network_vlan_ranges = physnet1:1:4094
</code></pre>
<h1 id="globals-file">Globals file</h1>
<p><code>vi /etc/kolla/globals.yml</code></p>
<pre><code class="language-yaml">---

kolla_internal_vip_address: "10.254.2.254"
neutron_external_interface: "eno1"
network_interface: "vlan.2"
keepalived_virtual_router_id: "66"

kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "rocky"

enable_keepalived: "yes"
enable_mariadb: "yes"
enable_memcached: "yes"
enable_rabbitmq: "yes"
enable_chrony: "yes"
enable_fluentd: "yes"
enable_nova_ssh: "yes"
enable_ceph: "no"
enable_horizon: "yes"

enable_haproxy: "yes"
kolla_enable_tls_external: "yes"

enable_nova: "yes"
nova_compute_virt_type: "kvm"

enable_keystone: "yes"
keystone_admin_user: "admin"
keystone_admin_project: "admin"

enable_glance: "yes"
glance_backend_file: "yes"

enable_cinder: "yes"
enable_cinder_backup: "no"
enable_cinder_backend_lvm: "yes"
cinder_volume_group: "cinder-volumes"
cinder_backend_ceph: "no"

enable_neutron: "yes"
enable_neutron_lbaas: "yes"
neutron_extension_drivers:
  - name: "port_security"
    enabled: true
  - name: "dns"
    enabled: true

enable_magnum: "yes"
enable_octavia: "no"
default_docker_volume_type: "local-lvm"
</code></pre>
<hr>
<h1 id="install-openstack-using-kolla-ansible">Install OpenStack using Kolla-Ansible</h1>
<pre><code class="language-bash">kolla-ansible certificates
kolla-ansible -i /etc/kolla/inventory bootstrap-servers
kolla-ansible -i /etc/kolla/inventory deploy
kolla-ansible -i /etc/kolla/inventory post-deploy
</code></pre>
<hr>
<h1 id="overcloud-cluster-configuration">Overcloud Cluster Configuration</h1>
<p>The OpenStack services are deployed, now to configure the cloud to be usable.</p>
<p>For details about these commands, see my previous VM guide <a href="/openstack-aio-ka-vm.html">here</a>.</p>
<p>These commands are ran right on the physical OpenStack host.</p>
<pre><code class="language-bash"># Authenticate to the cloud
source /etc/kolla/admin-openrc.sh

# Define the volume type in cinder
openstack volume type create --public local-lvm

# Create a provider network on VLAN 3
openstack network create --external --share \
  --provider-physical-network physnet1 --provider-network-type vlan \
  --provider-segment 3 --disable-port-security vlan3-net

# Assign a subnet to the vlan3-net network
openstack subnet create \
  --dhcp --network vlan3-net \
  --subnet-range 10.254.3.0/24 \
  vlan3-subnet

# Create a small cirros-sized flavor
openstack flavor create tiny --disk 1 --vcpus 1 --ram 256

# Download and import Cirros as a glance image
wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
apt-get install -y qemu-utils
qemu-img convert -f qcow2 -O raw cirros-0.4.0-x86_64-disk.img cirros.raw
openstack image create --container-format bare --disk-format raw \
  --file cirros.raw --public "cirros"

# Open up the firewall rules for the admin project
proj_id=$(openstack project list | grep admin | awk '{print $2}')
group_id=$(openstack security group list | grep $proj_id | awk '{print $2}')

openstack security group rule create --proto icmp $group_id
openstack security group rule create --proto tcp --dst-port 1:65535 $group_id
openstack security group rule create --proto udp --dst-port 1:65535 $group_id
</code></pre>
<hr>
<h1 id="create-a-test-vm">Create a test VM</h1>
<pre><code class="language-bash">openstack server create --image cirros --flavor tiny --network vlan3-net test
</code></pre>
<p>The cloud is now ready for use. If layer 3 routing from VLAN 2 to VLAN 3 is
configured, then the VM will be accessible.</p>


<p>I've found that it's pretty common that I need to send emails from my software.
At first it seems easy, there are well documented libraries out there. Pretty
soon though, your super critical outage notification email has wound up in the
SPAM filter.</p>
<p>In this project, I explore the tools available to send email alerts from your
automated systems and how to ensure those emails are trusted by their receiving
mail servers.</p>
<p>This will be an ongoing project that I intend to circle back to as time
permits.</p>
<hr>
<h1 id="project-posts--progress">Project Posts &#x26; Progress</h1>
<p>This project includes, or will include, the following posts.</p>
<table>
<thead>
<tr>
<th align="left">Date</th>
<th align="left">Article</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">2019-08-15</td>
<td align="left"><a href="/emails-postfix-ubuntu.html">Postfix Send-Only Mail Service: Basic emails from a dedicated VM</a></td>
</tr>
<tr>
<td align="left">2019-08-18</td>
<td align="left"><a href="/emails-bash-cron.html">Sending cron-scheduled ping failure alerts using a bash script</a></td>
</tr>
<tr>
<td align="left">2019-08-20</td>
<td align="left"><a href="/email-spf.html">Using SPF to ensure emails are trusted</a></td>
</tr>
</tbody>
</table>


<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#environment">Environment</a>
<ul>
<li><a href="#openstack-on-openstack-considerations">OpenStack-on-OpenStack Considerations</a>
<ul>
<li><a href="#disable-port-security">Disable Port Security</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#update-the-os">Update the OS</a></li>
<li><a href="#create-volume-group-for-cinder">Create Volume Group for Cinder</a></li>
<li><a href="#install-ansible">Install Ansible</a></li>
<li><a href="#install-kolla-ansible">Install Kolla-Ansible</a>
<ul>
<li><a href="#check-out-the-kolla-ansible-code">Check out the Kolla-Ansible code</a></li>
</ul>
</li>
<li><a href="#generate-openstack-config-files">Generate OpenStack Config Files</a>
<ul>
<li><a href="#openstack-service-config-files">OpenStack service config files</a></li>
<li><a href="#globals-file">Globals file</a></li>
<li><a href="#passwords-file">Passwords file</a></li>
<li><a href="#ansible-inventory">Ansible Inventory</a></li>
</ul>
</li>
<li><a href="#install-openstack-using-kolla-ansible">Install OpenStack using Kolla-Ansible</a>
<ul>
<li><a href="#install-the-openstack-command-line">Install the OpenStack Command Line</a></li>
</ul>
</li>
<li><a href="#overcloud-cluster-configuration">Overcloud Cluster Configuration</a>
<ul>
<li><a href="#source-the-admin-openrc-file">Source the Admin OpenRC file</a></li>
<li><a href="#create-a-cinder-volume-type">Create a Cinder Volume Type</a></li>
<li><a href="#create-a-flat-provider-network">Create a Flat Provider Network</a></li>
<li><a href="#up-the-interface">Up the interface</a></li>
<li><a href="#create-a-vxlan-for-workloads">Create a VXLAN for workloads</a></li>
<li><a href="#create-a-flavor">Create a flavor</a></li>
<li><a href="#create-an-image">Create an image</a></li>
<li><a href="#open-up-the-firewall">Open up the firewall</a></li>
</ul>
</li>
<li><a href="#create-a-test-vm">Create a test VM</a></li>
</ul>
<h1 id="environment">Environment</h1>
<p>These specs are what was used while writing this guide.
They are neither the minimum nor recommended requirements for a virtual
OpenStack cluster.</p>
<ul>
<li>VM hosted by <a href="https://breqwatr.com">Breqwatr</a>'s on-prem OpenStack
<ul>
<li>AWS/GCP/Azure can also host suitable VMs</li>
</ul>
</li>
<li>Ubuntu 18.04</li>
<li>2 vSSD volumes: 200GB for the OS and 300GB for Cinder LVM</li>
<li>2 VLAN ports: API interface and neutron interface</li>
<li>Docker images are the public Rocky images from Kolla on Docker Hub</li>
</ul>
<h2 id="openstack-on-openstack-considerations">OpenStack-on-OpenStack Considerations</h2>
<p>Skip this section if the installation is not on OpenStack.</p>
<h3 id="disable-port-security">Disable Port Security</h3>
<p>Turn off neutron port-security on each port.
Otherwise the unknown IPs will be blocked.</p>
<pre><code class="language-bash">for x in \
    3f664e5e-dd67-4fe5-b2cc-86c2918b6a2f \
    c44da3d5-00e7-4e41-af39-7010d70ac6a5; do
  echo $x
  openstack port set --no-security-group $x
  openstack port set --disable-port-security $x
done
</code></pre>
<hr>
<h1 id="update-the-os">Update the OS</h1>
<p>It will never be less risky to run an update than right now!</p>
<pre><code class="language-bash">apt-get update &#x26;&#x26; apt-get upgrade -y
</code></pre>
<hr>
<h1 id="create-volume-group-for-cinder">Create Volume Group for Cinder</h1>
<p>OpenStack Cinder supports a huge <a href="https://docs.openstack.org/cinder/rocky/reference/support-matrix.html">list of back-end storage providers</a>,
but the simplest to set up is just using an LVM volume group on the host.</p>
<p>Cinder will use LVM to carve out logical volumes for each cloud block storage
device. This isn't highly available, but that's OK for a dev cloud.</p>
<p>Create a volume group using a dedicated disk.
In this example, I'll use <code>/dev/vdb</code> for VMs.</p>
<p>The name of this volume group is defined in the globals.yml file as
<code>cinder_volume_group</code>, and can be changed as needed.</p>
<pre><code class="language-bash">pvcreate /dev/vdb
vgcreate cinder-volumes /dev/vdb
</code></pre>
<hr>
<h1 id="install-ansible">Install Ansible</h1>
<p>Kolla-Ansible requires that Ansible be pre-installed. Apt can install it too,
but pip tends to install a newer version. Some old versions aren't compatible
with Kolla-Ansible.</p>
<pre><code class="language-bash">apt-get -y install python python-pip
pip install ansible
</code></pre>
<hr>
<h1 id="install-kolla-ansible">Install Kolla-Ansible</h1>
<h2 id="check-out-the-kolla-ansible-code">Check out the Kolla-Ansible code</h2>
<p>Git comes pre-installed on many Ubuntu 18.04, but install it otherwise.</p>
<pre><code class="language-bash">apt-get install -y git
</code></pre>
<p>Clone a stable branch of Kolla-Ansible.
Check out the code and use pip to install it.</p>
<p>Make sure to use the stable branch associated with Rocky. Kolla-Ansible doesn't
work right when installing versions of OpenStack that don't match git stable
branch used.</p>
<pre><code class="language-bash">cd ~
git clone https://github.com/openstack/kolla-ansible.git
cd ~/kolla-ansible
git checkout stable/rocky
pip install .
</code></pre>
<hr>
<h1 id="generate-openstack-config-files">Generate OpenStack Config Files</h1>
<h2 id="openstack-service-config-files">OpenStack service config files</h2>
<p>Create a directory to store the OpenStack config changes.</p>
<pre><code class="language-bash">mkdir -p /etc/kolla/config
</code></pre>
<h2 id="globals-file">Globals file</h2>
<p>The globals file contains most of the important deployment settings for KA.</p>
<p>Check these two links for more info:</p>
<ul>
<li><a href="https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html">openstack.org KA advanced reference</a></li>
<li><a href="https://github.com/openstack/kolla-ansible/blob/master/etc/kolla/globals.yml">GitHub page for globals file</a></li>
</ul>
<p>Any configs not defined are set by defaults.yml files in KA's Ansible roles.</p>
<p>The globals file can specify your OpenStack version, where it will pull its
containers from, and which containers will be deployed. Be sure to replace
<code>kolla_internal_vip_address</code>'s value with your VIP address.</p>
<p>The VIP can't be used by your existing network card, else HAproxy will throw a
fit and Kolla-Ansible will fail at the MariaDB step.</p>
<p>The networking in this example is as simple as it gets. You can really split
things up in this file if you want to. Note the network interface name too, it
may be different from yours.</p>
<p><code>vi /etc/kolla/globals.yml</code></p>
<pre><code class="language-yaml">---
# APIs listen on this VIP
kolla_internal_vip_address: "10.100.202.254"

# Interface used for VXLANS and APIs. See docs to split this out into many nics
network_interface: "ens3"

# Used for the VLANS, give it the whole device
neutron_external_interface: "ens6"

# If you have more than one install in the broadcast domain, make this unique
keepalived_virtual_router_id: "77"

# Define the docker image names and tag (kolla/ubuntu-source-&#x3C;name>:rocky)
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "rocky"

# Which containers will be deployed
enable_keepalived: "yes"
enable_mariadb: "yes"
enable_memcached: "yes"
enable_rabbitmq: "yes"
enable_chrony: "yes"
enable_fluentd: "yes"
enable_nova_ssh: "yes"
enable_ceph: "no"
enable_horizon: "yes"

# Use HAProxy load balancer but disable TLS certs
enable_haproxy: "yes"
kolla_enable_tls_external: "yes"

# Use qemu for nested hypervisors, kvm for metal
enable_nova: "yes"
nova_compute_virt_type: "qemu"

# The default username and project can be changed here
enable_keystone: "yes"
keystone_admin_user: "admin"
keystone_admin_project: "admin"

# Glance stores VM templates. Use a file backend with cinder's LVM backend
enable_glance: "yes"
glance_backend_file: "yes"

# Configure Cinder to use the 'cinder-volumes' vg for virtual block devices
enable_cinder: "yes"
enable_cinder_backup: "no"
enable_cinder_backend_lvm: "yes"
cinder_volume_group: "cinder-volumes"
cinder_backend_ceph: "no"

# Enable the DNS ml2 extension driver in neutron &#x26; lbaas
enable_neutron: "yes"
enable_neutron_lbaas: "yes"
neutron_extension_drivers:
  - name: "port_security"
    enabled: true
  - name: "dns"
    enabled: true

# Configure magnum to look for the 'local-lvm' cinder volume type
enable_magnum: "yes"
default_docker_volume_type: "local-lvm"
</code></pre>
<h2 id="passwords-file">Passwords file</h2>
<p>The passwords file is empty initially, its just a template to be filled in with
random password from KA. The <code>kolla-genpwd</code> command populates it.</p>
<pre><code class="language-bash">cp ~/kolla-ansible/etc/kolla/passwords.yml /etc/kolla
kolla-genpwd
</code></pre>
<h2 id="ansible-inventory">Ansible Inventory</h2>
<p>The KA Ansible inventory defines which roles will be assigned to which hosts.
The all-in-one inventory file assigns all roles to localhost.</p>
<pre><code class="language-bash">cp ~/kolla-ansible/ansible/inventory/all-in-one /etc/kolla/inventory
</code></pre>
<hr>
<h1 id="install-openstack-using-kolla-ansible">Install OpenStack using Kolla-Ansible</h1>
<p>First run the bootstrap command to install docker and tune the server. In older
branches it will add the wrong key for the apt repo, so do that yourself.</p>
<pre><code class="language-bash">kolla-ansible certificates
kolla-ansible -i /etc/kolla/inventory bootstrap-servers
kolla-ansible -i /etc/kolla/inventory deploy
kolla-ansible -i /etc/kolla/inventory post-deploy
</code></pre>
<h2 id="install-the-openstack-command-line">Install the OpenStack Command Line</h2>
<p>This will enable the <code>openstack</code> command.</p>
<pre><code class="language-bash">pip install python-openstackclient python-neutronclient python-magnumclient
</code></pre>
<p>To configure the OpenStack CLI, source the openrc file that was created by KA's
post-deploy step.</p>
<pre><code class="language-bash">source /etc/kolla/admin-openrc.sh
</code></pre>
<hr>
<h1 id="overcloud-cluster-configuration">Overcloud Cluster Configuration</h1>
<p>Now that the undercloud is functional and the OpenStack services are running,
its time to configure the overcloud to be useful.</p>
<p>These commands are ran directly on the new virtual OpenStack host.</p>
<h2 id="source-the-admin-openrc-file">Source the Admin OpenRC file</h2>
<p>Kolla-Ansible's post-deploy task created an openrc file which can be used to
authenticate as the admin user it created. It's a good idea to make your own
user and openrc file, but for now this will do.</p>
<pre><code class="language-bash">source /etc/kolla/admin-openrc.sh
</code></pre>
<h2 id="create-a-cinder-volume-type">Create a Cinder Volume Type</h2>
<p>If no cinder volume type has been created, one must be made. These is required
for Magnum and for other storage backends, and also good practice.</p>
<pre><code class="language-bash">openstack volume type create --public local-lvm
</code></pre>
<h2 id="create-a-flat-provider-network">Create a Flat Provider Network</h2>
<p>Since this is OpenStack on OpenStack, using VLANs for the provider network is
more trouble than its worth. Make a flat network that shares the hosts
interface to provide workloads external network connectivity.</p>
<pre><code class="language-bash">openstack network create --share --external --disable-port-security \
  --provider-physical-network physnet1 --provider-network-type flat \
  infra-net

openstack subnet create \
  --no-dhcp --network infra-net \
  --allocation-pool start=10.100.202.180,end=10.100.202.199 \
  --subnet-range 10.100.202.0/24 \
  infra-subnet
</code></pre>
<h2 id="up-the-interface">Up the interface</h2>
<p><code>physnet1</code> is bound to <code>ens6</code> in this example, but that interface is down. Start
the interface.</p>
<pre><code class="language-bash">ip link set dev ens6 up
</code></pre>
<p>This is sort of a pain since it doesn't happen on reboot. There's a
<a href="https://bugs.launchpad.net/netplan/+bug/1763608">bug</a> in netplan about it, so
you can't just make a netplan entry.</p>
<p>One solution would be to make a crontab entry for <code>@reboot</code>, but I won't be
covering that here.</p>
<h2 id="create-a-vxlan-for-workloads">Create a VXLAN for workloads</h2>
<p>Create a VXLAN for VMs to use and plug it into the host's network using the
flat provider network.</p>
<pre><code class="language-bash">openstack network create vx1-net

openstack subnet create --network vx1-net --dhcp \
  --subnet-range 192.168.0.0/24 vx1-subnet

openstack router create --no-ha vx1-router
openstack router set --external-gateway infra-net vx1-router
openstack router add subnet vx1-router vx1-subnet
</code></pre>
<p>This flat provider network will now provide outbound internet access and the
ability to connect into workloads using floating IP addresses.</p>
<h2 id="create-a-flavor">Create a flavor</h2>
<pre><code class="language-bash">openstack flavor create tiny --disk 1 --vcpus 1 --ram 256
</code></pre>
<h2 id="create-an-image">Create an image</h2>
<p>This is the template used to launch our test VM</p>
<pre><code class="language-bash">wget http://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img
apt-get install -y qemu-utils
qemu-img convert -f qcow2 -O raw cirros-0.4.0-x86_64-disk.img cirros.raw
openstack image create --container-format bare --disk-format raw \
  --file cirros.raw --public "cirros"
</code></pre>
<h2 id="open-up-the-firewall">Open up the firewall</h2>
<p>Get the ID of the security group for the scoped project, in this case <code>admin</code>,
then open up ICMP, TCP, and UDP for that project.</p>
<pre><code>proj_id=$(openstack project list | grep admin | awk '{print $2}')
group_id=$(openstack security group list | grep $proj_id | awk '{print $2}')

openstack security group rule create --proto icmp $group_id
openstack security group rule create --proto tcp --dst-port 1:65535 $group_id
openstack security group rule create --proto udp --dst-port 1:65535 $group_id
</code></pre>
<hr>
<h1 id="create-a-test-vm">Create a test VM</h1>
<pre><code class="language-bash">openstack server create --image cirros --flavor tiny --network vx1-net test
# This server was assigned 192.168.0.13

openstack floating ip create infra-net
# The floating IP created was 10.100.202.226

openstack server add floating ip \
  --fixed-ip-address 192.168.0.13 test 10.100.202.226
</code></pre>
<p>You can now ping or SSH to your VM. The cloud is ready for use.</p>


<p>Google Cloud Storage has a feature where storage buckets can be used as a cost
effective web server. It can only host static sites, but that works just fine
for anything with all the logic on the client side.</p>
<p>Hosting a static website using Cloud Storage is <strong>extremely affordable</strong>.</p>
<p>This site is using this approach for hosting.</p>
<p><a href="https://cloud.google.com/storage/docs/hosting-static-website">The official documentation can be found here</a>.</p>
<hr>
<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#pricing">Pricing</a></li>
<li><a href="#add-the-domain-to-google-search-console">Add the Domain to Google Search Console</a></li>
<li><a href="#link-the-domain-name-to-your-storage-bucket">Link the Domain Name to Your Storage Bucket</a>
<ul>
<li><a href="#update-dns-cname-record">Update DNS CNAME Record</a></li>
<li><a href="#create-a-storage-bucket-with-matching-name">Create a Storage Bucket with Matching Name</a></li>
<li><a href="#configure-storage-bucket-for-access-control--index-file">Configure Storage Bucket for Access Control &#x26; Index File</a>
<ul>
<li><a href="#update-cloud-storage-bucket-permissions">Update Cloud Storage Bucket Permissions</a></li>
<li><a href="#configure-indexhtml-as-the-mainpagesuffix">Configure index.html as the MainPageSuffix</a></li>
<li><a href="#set-the-default-acl-for-the-bucket">Set the default ACL for the bucket</a></li>
</ul>
</li>
</ul>
</li>
<li><a href="#push-site-content-to-cloud-storage">Push Site Content to Cloud Storage</a></li>
</ul>
<h1 id="pricing">Pricing</h1>
<p><a href="https://cloud.google.com/storage/pricing">Find the latest pricing data from Google here</a>.</p>
<p>Google doesn't seem to actually charge for the static website hosting feature
of Cloud Storage. Instead, it just bills you for the storage usage. Notable is
that the operation usage cost will be far higher, and the data storage cost far
lower than in a typical Cloud Storage use case.</p>
<p>These prices are rough and there are lots of edge cases:</p>
<ul>
<li><strong>Data Storage</strong>: Free for the first 5GB, which will cover basically any
website. After that it's around  $0.026 US / GB / Month.</li>
<li><strong>Network Egress</strong>: Around $0.12/ GB</li>
<li><strong>Operations</strong>: This one will be higher. Every file served is an operation.
This includes the .html files, each image, the .css files, and so on. A CDN
such as <a href="https://dash.cloudflare.com/">Cloudflare</a> can help reduce the number
of read operations. After the first 50,000 free reads, Cloud Storage will
charge $0.004 / 10,000 operations.</li>
</ul>
<p>As you can see, for anything but hugely popular sites this will usually work
out to <em>almost free</em>.</p>
<hr>
<h1 id="add-the-domain-to-google-search-console">Add the Domain to Google Search Console</h1>
<p>A DNS TXT record containing a special string needs to be assigned to the domain
name that will be applied to the storage bucket. This is used to confirm
ownership of the domain.</p>
<p><strong>To add the domain to the search console:</strong></p>
<ol>
<li>Open the <a href="https://search.google.com/search-console/welcome">Google Search Console</a></li>
<li>Enter your domain name</li>
<li>Copy the TXT record they gave you and apply it to your domain. In Cloudflare
you go to your site, click DNS, Add Record, TXT. For kyle.pericak.com I used
<code>kyle</code> as the "Name" and the string from Google as the "Content". TTL Auto.</li>
<li>Go back to the search console page and verify</li>
<li>Click the link to go to your domain</li>
</ol>
<p>The domain name can now be bound to a Cloud Storage bucket.</p>
<p><strong>Note:</strong> I had a really hard time doing this with GoDaddy. The TXT change
would not propagate even after over 24 hours. I transferred my domain to
<a href="https://cloudflare.com/">Cloudflare</a>. Their updates apply basically right
away!</p>
<p>See also: <a href="/dns-xfer-godaddy-cloudflare.html">How I transferred the domain from GoDaddy to Cloudflare</a>.</p>
<hr>
<h1 id="link-the-domain-name-to-your-storage-bucket">Link the Domain Name to Your Storage Bucket</h1>
<h2 id="update-dns-cname-record">Update DNS CNAME Record</h2>
<p>Update the subdomain CNAME record to point to Google's API URL.
In Cloudflare I made a CNAME entry for <code>kyle.pericak.com</code> that looked like
this:</p>
<ul>
<li>Name: <code>kyle</code></li>
<li>Content: <code>c.storage.googleapis.com</code></li>
</ul>
<h2 id="create-a-storage-bucket-with-matching-name">Create a Storage Bucket with Matching Name</h2>
<p>Go to the <a href="https://console.cloud.google.com/storage/browser">Google Cloud Storage Browser</a>.
Click Create Bucket up at the top.</p>
<ol>
<li>Enter your FQDN in the bucket name. For example, I used <code>kyle.pericak.com</code></li>
<li>Location Type: Region</li>
<li>Location: northamerica-northeast1</li>
<li>Storage Class: standard</li>
<li>Access Control: Per-object (not bucket-only)</li>
<li>Encryption: Google managed keys</li>
<li>Create</li>
</ol>
<p>The storage bucket now exists and is ready to host the static content.</p>
<h2 id="configure-storage-bucket-for-access-control--index-file">Configure Storage Bucket for Access Control &#x26; Index File</h2>
<h3 id="update-cloud-storage-bucket-permissions">Update Cloud Storage Bucket Permissions</h3>
<p>Permit everyone to read the website files from Cloud Storage:</p>
<ol>
<li>From the sidebar go Storage</li>
<li>Click the 3 dots to the right of this storage bucket</li>
<li>Edit Bucket Permissions</li>
<li>New Members: <code>allUsers</code></li>
<li>Add the role <code>Storage Object Viewer</code></li>
</ol>
<h3 id="configure-indexhtml-as-the-mainpagesuffix">Configure index.html as the MainPageSuffix</h3>
<p>Cloud Storage doesn't know where the page root is by default. Define it:</p>
<ol>
<li>Click on the 3 dots to the right of the bucket name</li>
<li>Click Edit Website Configuration</li>
<li>Main page: index.html</li>
</ol>
<h3 id="set-the-default-acl-for-the-bucket">Set the default ACL for the bucket</h3>
<p>If this isn't done then the website will show XML with an error stating
<code>Anonymous caller does not have storage.objects.list access</code>.</p>
<p><strong>Option 1: Using gsutil:</strong></p>
<pre><code class="language-bash">gsutil defacl ch -u AllUsers:R gs://kyle.pericak.com
</code></pre>
<p><strong>Option 2: From the web UI:</strong></p>
<ol>
<li>Open <a href="https://console.cloud.google.com/storage/">console.cloud.google.com/storage/</a>.</li>
<li>Go to the bucket named after the domain</li>
<li>Permissions</li>
<li>The permissions can be modified here.</li>
</ol>
<hr>
<h1 id="push-site-content-to-cloud-storage">Push Site Content to Cloud Storage</h1>
<p>While its possible to manually upload each file using the web UI, it would be
super tedious.</p>
<p>Run the <code>gsutil rsync</code> module to upload files at all once.
Note that <code>$dst_url</code> is pointing at my domain-associated cloud storage bucket.</p>
<pre><code class="language-bash"># -r    recurse - sync directories
# -c    compare checksums instead of mtime
# -d    Delete extra files under dst_url not found under src_url
src_url="./output"
dst_url="gs://kyle.pericak.com"
gsutil -m rsync -r -c -d $src_url $dst_url
</code></pre>


<p>I owned some domain names that used godaddy.com as their registrar. With
Godaddy it takes <strong>forever</strong> for changes to propagate, which can be a real
problem when you need to update TXT records.</p>
<p>Cloudflare is awesome in that they're really affordable for domains, have
really nice CDN capabilities, don't charge you for "protection", and their DNS
changes replicate super fast.</p>
<p>Here's how to move a domain from Godaddy to Cloudflare.</p>
<h1 id="steps">Steps</h1>
<h2 id="unlock-the-domain">Unlock the Domain</h2>
<ol>
<li>Log into Godaddy</li>
<li>Go to <a href="https://dcc.godaddy.com/domains/">My Domains</a> and select your domain</li>
<li>Click "Edit" next to <code>Domain lock: On</code> to show the slider. Set it to "off".</li>
</ol>
<h2 id="get-your-transfer-authorization-code">Get your transfer authorization code</h2>
<ol>
<li>Log into Godaddy</li>
<li>Go to <a href="https://dcc.godaddy.com/domains/">My Domains</a> and select your domain</li>
<li>Click 'Transfer domain away from GoDaddy'</li>
<li>Continue with transfer</li>
<li>Skip whatever annoying ads they give you</li>
<li>Go to your email and get your registration code</li>
</ol>
<h2 id="transfer-the-domain-to-cloudflare">Transfer the Domain to Cloudflare</h2>
<p>If you haven't added your site yet, add it now in Cloudflare. You need to add
the nameserver settings too before you can transfer it. This tripped me up,
since I hadn't redirected the nameservers from GoDaddy's default ones to
Cloudflare's yet.</p>
<ol>
<li>From Cloudflare's dashboard, go to Domain Registration</li>
<li>It should let you choose your domain here. If it says there are none
available, you haven't set up your existing domain with them yet.</li>
<li>Enter your auth code, click Confirm Authorization Codes</li>
<li>Fill out the contact info, Confirm and Finalize Transfer</li>
</ol>
<p>That's it, your domain is now transferred to Cloudflare</p>
<h1 id="references">References</h1>
<ul>
<li><a href="https://developers.cloudflare.com/registrar/transfer-instructions/godaddy/">Cloudflare transfer guide</a></li>
<li><a href="https://ca.godaddy.com/help/unlock-my-domain-for-transfer-410">GoDaddy unlock for xfer</a></li>
</ul>


<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#pricing">Pricing</a></li>
<li><a href="#write-the-cloud-build-file">Write the Cloud Build file</a></li>
<li><a href="#iam-roles">IAM Roles</a>
<ul>
<li><a href="#docker-image-to-cloud-registry">Docker Image to Cloud Registry</a></li>
<li><a href="#static-website-to-google-cloud-storage">Static Website to Google Cloud Storage</a></li>
</ul>
</li>
<li><a href="#define-cloud-build-triggers">Define Cloud Build Triggers</a></li>
</ul>
<h1 id="pricing">Pricing</h1>
<p>Current pricing data can be found <a href="https://cloud.google.com/cloud-build/pricing">here</a>.</p>
<ul>
<li>For the first 120 builds in a day, cloud build is <strong>free</strong>.</li>
<li>each build after the free quota costs $0.003 US / build-minute when using the
single core build server with no additional SSD storage</li>
</ul>
<h1 id="write-the-cloud-build-file">Write the Cloud Build file</h1>
<p>Google Cloud Build uses a file, <code>cloudbuild.yml</code>, to define the tasks that will
be executed when a build is triggered.</p>
<p>The online references for the syntax are pretty good:</p>
<ul>
<li><a href="https://cloud.google.com/cloud-build/docs/build-config">Google's Cloud-Build Documentation</a></li>
<li><a href="https://cloud.google.com/cloud-build/docs/configuring-builds/substitute-variable-values">Variables Available in cloudbuild.yaml</a></li>
</ul>
<p>Below are some example configuration files used for this site.</p>
<h1 id="iam-roles">IAM Roles</h1>
<p><a href="https://cloud.google.com/cloud-build/docs/securing-builds/configure-access-control">Official Documentation</a></p>
<ul>
<li>Cloud Build Editor</li>
<li>Cloud Build Viewer</li>
</ul>
<h2 id="docker-image-to-cloud-registry">Docker Image to Cloud Registry</h2>
<p>Cloud Build is great for keeping your Docker Registry images aligned with your
version control code.</p>
<p>In this example I use Cloud Build to build and push a <a href="/docker-pelican-image.html">pelican image</a>
to the <a href="/google-container-registry.html">Google Container Registry</a>.</p>
<p>Be sure to keep the Dockerfile code in version control. Aside from being a good
idea in general, Cloud Build can also use Git commits as a build trigger.
<a href="https://github.com/kylep/pelican">Here's my Pelican Docker image repository</a>.</p>
<pre><code class="language-yaml">steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'gcr.io/$PROJECT_ID/pelican', '.' ]
images:
- 'gcr.io/$PROJECT_ID/pelican'
</code></pre>
<h2 id="static-website-to-google-cloud-storage">Static Website to Google Cloud Storage</h2>
<p>Another use for Cloud Builder is to generate static website files and then sync
them up with Cloud Storage every time the source control files or template are
changed.</p>
<p>Here's an example that triggers when I commit code to my
<a href="https://github.com/kylep/kyle.pericak.com">blog content git repository</a>. It
copies the content into <code>/workspace</code> and uses the above pelican image to render
the content and output it to the <code>output/</code> directory.</p>
<p>Once the site content is generated, the next step uses the <code>gcloud</code> image's
<code>gsutil -m rsync</code> command to upload the files to the Google Storage Bucket.</p>
<hr>
<h1 id="define-cloud-build-triggers">Define Cloud Build Triggers</h1>
<p>Here's the procedure I used to link a Cloud Build trigger to my Pelican image.</p>
<ol>
<li>Go to <a href="https://console.cloud.google.com/cloud-build">Google Cloud-Build</a>.</li>
<li>On the left side-bar, navigate to Triggers</li>
<li>Add Trigger</li>
<li>Select source: GitHub</li>
<li>Authenticate: Log in if needed</li>
<li>Select Repository: This is the repo that will be watched for changes</li>
<li>Name: This is the name of the trigger</li>
<li>Description: Something like <code>Push to master branch</code></li>
<li>Trigger Type: <code>Branch</code></li>
<li>Branch: <code>master</code></li>
<li>Build Configuration: <code>cloudbuild.yaml</code></li>
<li><strong>Create Trigger</strong></li>
</ol>
<p>With this trigger in place, all pushes to the pelican project will trigger the
rebuilding of its image, followed by updating the image in GCR with the latest
changes.</p>


<h3 id="table-of-contents">Table of Contents</h3>
<ul>
<li><a href="#why-use-google-container-registry">Why use Google Container Registry</a></li>
<li><a href="#pricing">Pricing</a></li>
<li><a href="#command-line">Command Line</a></li>
<li><a href="#authentication">Authentication</a>
<ul>
<li><a href="#create-a-service-account">Create a service account</a></li>
<li><a href="#authenticate-your-local-docker-client">Authenticate your local Docker client</a></li>
</ul>
</li>
<li><a href="#using-the-google-container-registry">Using the Google Container Registry</a>
<ul>
<li><a href="#pull-image">Pull Image</a></li>
<li><a href="#push-image">Push Image</a>
<ul>
<li><a href="#access-denied">Access Denied</a></li>
</ul>
</li>
<li><a href="#delete-an-image">Delete an Image</a></li>
</ul>
</li>
</ul>
<h1 id="why-use-google-container-registry">Why use Google Container Registry</h1>
<p>The Google Container Registry is a SaaS version of the public <a href="https://hub.docker.com/_/registry">Registry</a>
docker image. It solves a number of problems that the public Docker image has.
Namely:</p>
<ul>
<li><strong>Authentication</strong>: GCR has built-in access controls, where the Registry image
does not. With the Docker Registry you need to put something like NGINX in
front of it to provide access control.</li>
<li><strong>HTTPS</strong>: Like with the authentication problem, Registry needs a reverse proxy
in front of it to serve a certificate. Also, you need to worry about
obtaining and maintaining the valid cert files. Without a valid cert, each
Docker client needs to list the registry as an insecure registry, which is
both insecure and inconvenient.</li>
<li><strong>Serverless</strong>: To host a traditional Docker registry, you need a public
server running Docker. With Google's Container Registry, there's no server to
maintain.</li>
<li><strong>Vulnerability Scanning</strong>: GCR can <a href="https://cloud.google.com/container-registry/docs/get-image-vulnerabilities">scan your images for security issues</a>.</li>
</ul>
<hr>
<h1 id="pricing">Pricing</h1>
<p>The pricing is well documented <a href="https://cloud.google.com/container-registry/pricing">here</a>,
and it has a lot of variables.</p>
<p>Basically though, it boils down to the following approximate costs:</p>
<ul>
<li><strong>Storage</strong>: $0.026 USD / GB / month</li>
<li><strong>Network</strong>: ~ $0.12 USD / GB</li>
<li><strong>Vulnerability Scanning</strong>: $0.26 per scanned image</li>
</ul>
<hr>
<h1 id="command-line">Command Line</h1>
<p>GCR can be managed from the web UI or the command line. I try and keep my steps
limited to the web UI, but the command line is really easy to use. You can find
its documentation <a href="https://cloud.google.com/sdk/gcloud/reference/container/images">here</a>.</p>
<hr>
<h1 id="authentication">Authentication</h1>
<p>Before you start, be sure to install:</p>
<ul>
<li><a href="https://cloud.google.com/sdk/">Google Cloud SDK</a></li>
<li><a href="https://docs.docker.com/install/">Docker</a></li>
</ul>
<p>To interact with Google Container Registry you need to first authenticate your
local Docker client. Usually this is done with the <code>docker login &#x3C;registry></code>
command, but that's not how it's done with Google container registry. Instead
we'll use the <code>gcloud</code> command line.</p>
<h2 id="create-a-service-account">Create a service account</h2>
<p>While this isn't strictly necessary, it's good practice.</p>
<p>The container registry uses GCS buckets to store the images. It doesn't have
dedicated roles, and instead uses the GCS roles. You can find a detailed list
of the roles <a href="https://cloud.google.com/container-registry/docs/access-control">here</a>.
The two important roles are <code>roles/storage.admin</code> for write and
<code>roles/storage.objectViewer</code> for read.</p>
<p>To create the SA from the Google Cloud Web UI:</p>
<ol>
<li>Open the <a href="https://console.cloud.google.com/iam-admin/serviceaccounts">IAM Service Accounts page</a></li>
<li>If needed, select or create your project</li>
<li>Click <code>Create Service Account</code></li>
<li>Create a member, such as <code>gcr-readonly</code> or <code>gcr-admin</code>.
When possible, its nice to have the account name and account ID match.</li>
<li>Assign a useful description to the service-account.</li>
<li>Assign a role. <code>Storage Object Viewer</code> grants read access and
<code>Storage Admin</code>.</li>
<li>Create and download a key. Name it something like <code>gcr-readonly.json</code>.</li>
</ol>
<h2 id="authenticate-your-local-docker-client">Authenticate your local Docker client</h2>
<p>Use the <code>gcloud</code> tool to deploy some <code>credHelpers</code> to <code>~/.docker/config.json</code>.</p>
<pre><code class="language-bash">gcloud auth configure-docker --project &#x3C;project name>
</code></pre>
<p>Next up, it's time to authenticate.</p>
<p>You could run <code>gcloud auth login</code>, but that doesn't use the service account we
just created and also requires a browser to open a generated link.</p>
<p>Instead, use the service account's JSON file generated in the above step with
the <code>--key-file</code> argument as follows:</p>
<pre><code class="language-bash">gcloud auth activate-service-account --key-file /vagrant/auth/gcr-readonly.json
</code></pre>
<p>If successful, you'll get a confirmation message:</p>
<pre><code class="language-bash">Activated service account credentials for: [gcr-readonly@*.gserviceaccount.com]
</code></pre>
<hr>
<h1 id="using-the-google-container-registry">Using the Google Container Registry</h1>
<p>The GCR works just like any other registry once you've ran the <code>gcloud auth</code>
command. You don't need to run any <code>docker login</code> command.</p>
<h2 id="pull-image">Pull Image</h2>
<p>Here's how to pull a Pelican image from GCR:</p>
<pre><code class="language-bash">docker pull gcr.io/myProject/pelican
</code></pre>
<h2 id="push-image">Push Image</h2>
<p>It's pretty straightforward. Replace <code>myProject</code> with your project name.</p>
<p>In this example I add a tag to my pelican image, calling it <code>pelican2</code>, and
push it up to the registry as a new image. You'd normally make your own Docker
image.</p>
<pre><code class="language-bash">sudo docker tag gcr.io/myProject/pelican gcr.io/myProject/pelican2
sudo docker push gcr.io/myProject/pelican2
</code></pre>
<p>If you didn't get an error, then the image is now pushed.</p>
<h3 id="access-denied">Access Denied</h3>
<p>If you receive the following message, your user account lacks write access:</p>
<pre><code class="language-text">denied: Token exchange failed for project 'myProject'. Caller does not have permission 'storage.buckets.get'.
</code></pre>
<p>To resolve this, create a service account  with the role <code>roles/storage.admin</code>.
If there's a finer grained access level to permit this, I'd be interested to
hear about it.</p>
<pre><code class="language-bash">gcloud auth activate-service-account --key-file /vagrant/auth/gcr-admin.json
sudo docker push gcr.io/kylepericak/pelican2
</code></pre>
<h2 id="delete-an-image">Delete an Image</h2>
<p>At the time of writing this, there's a warning in the cloud UI saying that you
can't delete images unless you use the CLI.</p>
<p>Here's how to do that. Be sure to replace <code>myProject</code> with your project.</p>
<pre><code class="language-bash"># List current images
gcloud config set project myProject

# Ignore this warning if you're using a service account:
# WARNING: You do not appear to have access to project [myProject] or it does not exist.

# Delete the image
cloud container images delete gcr.io/myProject/pelican2
</code></pre>


<p><strong>This post is linked to from the <a href="/blog-website.html">Blog Website Project</a></strong></p>
<hr>
<p>Nobody wants to test in production.</p>
<p>This guide covers how to preview your Pelican content locally as you write it.
Every time you save a markdown file or update the Pelican theme, the entire
site will re-generate and be hosted by a local web-server for you to review.</p>
<h1 id="install-dependencies">Install Dependencies</h1>
<ul>
<li><a href="https://docs.docker.com/install/">Docker</a></li>
<li><a href="https://git-scm.com/book/en/v2/Getting-Started-Installing-Git">Git</a></li>
<li>Text Editor: Your choice, I use <a href="https://github.com/vim/vim">Vim</a></li>
<li>Browser: Chrome has nice developer tools but anything works</li>
</ul>
<hr>
<h1 id="get-the-pelican-image">Get the Pelican Image</h1>
<p><strong>Option 1: Build your own</strong></p>
<p>This is the approach I suggest. You can see the guide I wrote explaining how to
build a Pelican image <a href="/docker-pelican-image.html">here</a>.</p>
<p><strong>Option 2: Use a pre-made image</strong>
I've shared my image for public use <a href="https://hub.docker.com/r/kpericak/pelican">here</a>.
If you plan on using it, you're best bet is to check how I use it on GitHub.</p>
<hr>
<h1 id="launch-a-persistent-pelican-container">Launch a Persistent Pelican Container</h1>
<p>Once you've either pulled or built the image, it will be listed in your Docker
image list.</p>
<pre><code class="language-bash">docker image list
</code></pre>
<p>Set the following variables. Note the paths should be absolute (vs relative).</p>
<ul>
<li><code>$image_name</code>: docker image name</li>
<li><code>$conf_file</code>: path to <code>pelicanconf.py</code> configuration file</li>
<li><code>$content_dir</code>: path to <code>content/</code> directory, where markdown files reside</li>
<li><code>$output_dir</code>: path to <code>output/</code> directory, where generated files will land.</li>
<li><code>$listen_port</code>: Which port to listen on for the dev web-server</li>
</ul>
<p>Optionally, you can set a theme path too. If you omit this and its associated
volume mount then the theme built into the Pelican image will be used instead.
This enables theme development.</p>
<ul>
<li><code>$theme_path</code>: Path to the Pelican theme</li>
</ul>
<p>Start the Docker container in daemon mode (<code>-d</code>)  as persistent container.
By setting the run command to <code>tail -f /dev/null</code>, the container will never
stop itself and instead sit idle until told to do otherwise.</p>
<p>Mount the directories specified by those variables into the container.</p>
<p>Forward <code>$listen_port</code> to the workstation so the site can be opened in a local
browser.</p>
<pre><code class="language-bash">image_name=""
conf_file=""
content_dir=""
output_dir=""
theme_path=""
listen_port=8000

docker run -d \
  --name pelican \
  -v $conf_file:/pelicanconf.py \
  -v $conftent_dir:/content \
  -v $output_dir:/output \
  -v $theme_path:/theme" \
  -p 0.0.0.0:$listen_port:8000 \
  image_name \
  tail -f /dev/null
</code></pre>
<hr>
<h1 id="launch-development-web-server">Launch Development Web-Server</h1>
<p>At this point you have a pelican container running, but it isn't doing
anything. The files are all mounted in, and it's prepared to forward its local
port 8000 to your specified workstation port, so all that's left is to start
Pelican's built-in development service.</p>
<p>This service will watch both the markdown files and the theme files for
changes, then reload the site files. It will also host the website on a
non-production web-server.</p>
<pre><code class="language-bash">docker exec -it pelican \
  pelican \
    -s /pelicanconf.py \
    --debug \
    --autoreload \
    --listen \
    --port 8000 \
    --bind 0.0.0.0 \
    /content \
    -o /output
</code></pre>


<h1 id="what-is-pelican">What is Pelican</h1>
<p><a href="https://github.com/getpelican/pelican">Pelican</a> is a free and open source
static website generator. It takes a collection of files
written in <a href="https://en.wikipedia.org/wiki/Markdown">Markdown</a> as its input,
applies a theme and configuration, then outputs a full static website.</p>
<p>A static website is a collection of HTML and CSS files that don't need any
database or back-end programming language. These websites can be hosted by any
web-server regardless of language support.</p>
<hr>
<h1 id="creating-a-pelican-project">Creating a Pelican Project</h1>
<p>While not necessary, its a really good idea to make a git project to source
control your blog content.</p>
<p>The project will hold the configuration for Pelican, which defines the plugins,
variables for the style-sheet, and the site name. This project also holds all
the markdown files which make up the blog content.</p>
<h2 id="project-layout">Project Layout</h2>
<p>The files should be placed in a structure as follows.</p>
<ul>
<li>Configuration goes in the <code>pelicanconf.py</code> file.</li>
<li>Blog posts go in <code>content/posts</code>, and can be sorted into subdirectories.
The nested directory structure has no impact on how the site is rendered.</li>
<li>Static pages go in <code>content/pages</code>. These are handled specially by the
templating engine.</li>
<li><code>content/images</code> stores image files</li>
<li><code>output/</code> doesn't need to exist here, but it's used by the <code>-o</code> (output)
argument in Pelican as the directory to store the generated website files.
This directory should be ignored by Git.</li>
</ul>
<pre><code class="language-text">.
+-- pelicanconf.py
+-- content/
|   +-- posts/
|       +-- first.md
|       +-- how-this-site-works/
|           +-- building-a-website.md
|   +-- pages/
|       +-- about.md
|   +-- images/
|       +-- pelican.png
+-- output/
</code></pre>
<hr>
<h1 id="pelican--markdown-syntax-reference">Pelican &#x26; Markdown Syntax Reference</h1>
<h2 id="post-metadata">Post Metadata</h2>
<p>The top of each post starts with some metadata that Pelican uses to scaffold
the site.</p>
<pre><code class="language-text">title: Title of the post or page
summary: Detailed summary
slug: short-name-goes-in-the-url
category: whereThisWillBeSorted
tags: tag1, tag2
date: 2019-08-28
modified: 2019-08-28
status: published or draft
</code></pre>
<ul>
<li><code>title</code>: defines the string at the top of the article and in the index</li>
<li><code>summary</code>: used in the index pages. If not defined, a large and
somewhat ugly subset of the top part of your post will auto-populate this
field.</li>
<li><code>slug</code>: defines the URL from which the post page is accessible</li>
<li><code>category</code>: place this post into a category, accessible from the sidebar in
this particular theme.</li>
<li><code>tags</code>: a comma delimited list of indexed sub-categories. Can have many.</li>
<li><code>date</code>: When the page was authored</li>
<li><code>modified</code>: When the page was last changed</li>
<li><code>status</code>: either <code>published</code> or <code>draft</code>. Defines whether the page is ready to
be displayed to the public.</li>
</ul>
<p>You can also define custom attributes to use in your themes. I've modified a
theme to allow custom thumbnail files for the index and a blog image which look
like this:</p>
<pre><code class="language-text">image: pelican.png
thumbnail: pelican-thumb.png
</code></pre>
<h2 id="headers">Headers</h2>
<pre><code class="language-text">Regular text
# Big header (h1)
## Smaller Header (h2)
### Even smaller header
</code></pre>
<h2 id="horizontal-line">Horizontal Line</h2>
<pre><code class="language-text">---
</code></pre>
<h2 id="table-of-contents">Table of Contents</h2>
<ul>
<li>
<ul>
<li><a href="#numbered-list">Numbered List</a></li>
<li><a href="#bullet-list">Bullet List</a></li>
<li><a href="#html">HTML</a></li>
<li><a href="#links">Links</a></li>
<li><a href="#images">Images</a></li>
</ul>
</li>
<li><a href="#preview-the-site">Preview the Site</a>
<ul>
<li><a href="#pull-the-pelican-image">Pull the Pelican Image</a></li>
<li><a href="#launch-the-pelican-container">Launch the Pelican container</a></li>
<li><a href="#launch-the-local-web-server-and-auto-rebuild-service">Launch the local web server and auto-rebuild service</a></li>
<li><a href="#browse-to-your-site">Browse to your site</a></li>
</ul>
</li>
<li><a href="#reference-links">Reference Links</a></li>
<li><a href="#next-up">Next Up</a></li>
</ul>
<h2 id="numbered-list">Numbered List</h2>
<p>The numbers will automatically increment.</p>
<pre><code class="language-text">1. First item
1. Second item
1. Third Item
</code></pre>
<h2 id="bullet-list">Bullet List</h2>
<pre><code class="language-text">- First Item
- Second Item
    - Nested List item with 4 spaces before the dash
- Third Item
</code></pre>
<h2 id="html">HTML</h2>
<p>Markdown files can also support raw HTML content, allowing you a lot of
flexibility.</p>
<pre><code class="language-html">&#x3C;table class="mytable>
  &#x3C;tr>&#x3C;th>Header&#x3C;/th>&#x3C;/tr>
  &#x3C;tr>&#x3C;td>Cell&#x3C;/td>&#x3C;/td>&#x3C;/tr>
&#x3C;/table>
</code></pre>
<h2 id="links">Links</h2>
<p>Linked text goes in square brackets the URL in round brackets.</p>
<pre><code class="language-text">[A web link](https://example.com)
</code></pre>
<h2 id="images">Images</h2>
<pre><code class="language-text">![Alt Text](/images/blog_workflow.png)
</code></pre>
<hr>
<h1 id="preview-the-site">Preview the Site</h1>
<p>The content is ready to be converted into a website. Use a Pelican container to
generate the site. The pelican container can also act as a local web server to
preview changes before pushing them.</p>
<h2 id="pull-the-pelican-image">Pull the Pelican Image</h2>
<p>Pull a pelican image from GCR or Docker Hub.
Mine is <code>gcr.io/kylepericak/pelican</code> on GCR and <code>kpericak/pelican</code> on Docker
Hub. The GCR image is private, since they charge me for the downloads.</p>
<pre><code class="language-bash">docker pull gcr.io/kylepericak/pelican
# or
docker pull kpericak/pelican
</code></pre>
<h2 id="launch-the-pelican-container">Launch the Pelican container</h2>
<p>Run this from the project root. It will mount the content/ and output/
directories into a new container named "pelican". It will also forward the
port Pelican's web server listens on (8000) to the workstation's port 8888.</p>
<p>The Pelican auto-reload feature looks like maybe its multithreaded or something,
so running it as the root process of the docker container doesn't work.
Instead, launch the container with the <code>tail -f /dev/null</code> command so it just
idles.</p>
<pre><code class="language-bash">docker run -d \
  --name pelican \
  -v $(pwd)/content:/content \
  -v $(pwd)/output:/output \
  -p 8888:8000 \
  gcr.io/kylepericak/pelican \
  tail -f /dev/null
</code></pre>
<h2 id="launch-the-local-web-server-and-auto-rebuild-service">Launch the local web server and auto-rebuild service</h2>
<p>This will build the site files, launch the web server, and watch for new
file changes so it can automatically rebuild.</p>
<p>The example <code>docker exec</code> command runs interactively. I like to run it in a
dedicated tmux pane to show if anything has gone wrong.</p>
<pre><code class="language-bash">docker exec -it pelican \
  pelican \
    -s /pelicanconf.py \
    --debug \
    --autoreload \
    --listen \
    /content \
    -o /output
</code></pre>
<h2 id="browse-to-your-site">Browse to your site</h2>
<p><a href="http://localhost:8888">http://localhost:8888</a></p>
<hr>
<h1 id="reference-links">Reference Links</h1>
<ul>
<li><a href="http://docs.getpelican.com/en/3.6.3/content.html">Official Pelican Syntax Reference</a></li>
</ul>
<hr>
<h1 id="next-up">Next Up</h1>
<p>Now that the content is written, its time to
<a href="/htsw-4-gcs-static-website.html">host the static website on Google Cloud Storage</a>.</p>


<p><strong>This post is linked to from the <a href="/blog-website.html">Blog Website Project</a></strong></p>
<hr>
<p>Pelican is a free and open source static website generator written in Python.
It accepts a theme, a config file, and a directory of markdown documents as
input and uses them to generate the HTML and CSS files that make up a static
website.</p>
<p>This post covers how to build a Docker image that contains the Pelican software
and the theme which I chose to use with it. This image is reusable and
<a href="https://hub.docker.com/r/kpericak/pelican">freely available on Docker Hub</a>.</p>
<h1 id="dockerfile">Dockerfile</h1>
<p>As with any Docker image, the most important piece is the Dockerfile.</p>
<p>You can see the current file I'm using <a href="https://github.com/kylep/pelican/blob/master/Dockerfile">here</a>.</p>
<p>In this Dockerfile, Pelican, its theme, and plugins are installed to the image.</p>
<pre><code class="language-text">FROM ubuntu:bionic
ADD requirements.txt ./
RUN apt-get update \
    &#x26;&#x26; apt-get install -y --no-install-recommends \
         git \
         python \
         python-pip \
         python-setuptools \
    &#x26;&#x26; rm -rf /var/lib/apt/lists/* \
    &#x26;&#x26; pip install -r requirements.txt \
    &#x26;&#x26; git clone https://github.com/kylep/voidy-bootstrap.git /theme \
    &#x26;&#x26; mkdir -p /tmp-plugins/ /plugins \
    &#x26;&#x26; git clone --recurse \
           https://github.com/getpelican/pelican-plugins.git /tmp-plugins \
    &#x26;&#x26; cp -r /tmp-plugins/series /plugins/ \
    &#x26;&#x26; rm -r /tmp-plugins
</code></pre>
<h3 id="from-ubuntubionic">FROM ubuntu:bionic</h3>
<p>This section specifies the Docker base image. The above docker file uses
<a href="https://hub.docker.com/_/ubuntu/">the official Docker Hub Ubuntu image</a>.</p>
<h3 id="add-requirementstxt">ADD requirements.txt</h3>
<p>The requirements.txt file lists the python packages which Pelican depends upon.
Docker's <code>ADD</code> will copy that file into the image at the specified path.</p>
<p>The minimum packages required are:</p>
<pre><code class="language-text">pelican
markdown
</code></pre>
<h3 id="run-">RUN ...</h3>
<p>The run task is basically a bash script all squished into one line. While its
harder to read with all the line continuation and <code>&#x26;&#x26;</code> symbols, using them
leads to Docker only building a single layer.</p>
<p><a href="https://docs.docker.com/develop/develop-images/dockerfile_best-practices/">See the best practices for writing docker images</a>.</p>
<p>Since this is an Ubuntu image, <code>apt</code> is the package manager. It installs Git
and some python packages. Git is required to pull the Pelican theme from
Github.</p>
<p>Only the minimum Python packages are installed by apt, since pip is the
preferred python package manager.</p>
<p><code>rm -rf /var/lib/apt/lists/*</code> removes the leftover apt artifacts, helping to
shrink the Docker image.</p>
<p>After the theme is pulled from GitHub, Pelican's open source plugins are also
pulled. The ones desired are copied to <code>/plugins</code>, then the (huge) checkout is
deleted to reduce image size.</p>
<hr>
<h1 id="running-the-docker-image">Running the Docker Image</h1>
<p>Locally, you need to mount the content into the container. Something like this
will work:</p>
<pre><code class="language-bash">docker run \
  --name pelican \
  -v $(pwd):/workspace \
  gcr.io/kylepericak/pelican:latest \
  pelican -o /workspace/output -s /workspace/pelicanconf.py
</code></pre>
<p>The above command will load the <code>content/</code> and <code>pelicanconf.py</code> files into
Pelican, and write the static website to <code>output/</code>.</p>


<p>The objective of this project is to build a technology blog website,
satisfying the following requirements:</p>
<ul>
<li><strong>Affordable</strong>: The website should cost as little as possible to maintain</li>
<li><strong>Maintainable</strong>: Authoring and updating content on the website should be
simple and fast.</li>
<li><strong>Extensible</strong>: This is a software developer's website. It needs to enable
custom code so fun features can be built into it.</li>
<li><strong>Custom Domain</strong>: Some free/cheap blog options require a custom FQDN suffix,
such as <code>x.wordpress.com</code> sites. This blog needs to work with any domain
name.</li>
<li><strong>Fun</strong>: The blog needs to use technologies that are current and interesting.</li>
</ul>
<hr>
<h1 id="project-posts--progress">Project Posts &#x26; Progress</h1>
<p>This project includes, or will include, the following posts.
If any aren't finished, check back later!</p>
<table>
<thead>
<tr>
<th align="left">Date</th>
<th align="left">Article</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">2019-08-01</td>
<td align="left"><a href="/docker-pelican-image.html">Building a Pelican Docker image</a></td>
</tr>
<tr>
<td align="left">2019-08-03</td>
<td align="left"><a href="/writing-pelican-content.html">Writing blog content for Pelican</a></td>
</tr>
<tr>
<td align="left">2019-08-04</td>
<td align="left"><a href="/pelican-dev-environment.html">A simple Pelican development environment</a></td>
</tr>
<tr>
<td align="left">2019-08-05</td>
<td align="left"><a href="/google-container-registry.html">Saving Docker images in Google's Container Registry</a></td>
</tr>
<tr>
<td align="left">2019-08-06</td>
<td align="left"><a href="/google-cloud-build.html">Google Cloud Build with GitHub Trigger</a></td>
</tr>
<tr>
<td align="left">2019-08-09</td>
<td align="left"><a href="/google-cloud-storage-website.html">Hosting a website using Google Cloud Storage</a></td>
</tr>
<tr>
<td align="left">2019-12-02</td>
<td align="left"><a href="/cloudflare-https.html">Using Cloudflare to provide HTTPS</a></td>
</tr>
</tbody>
</table>
<hr>
<h1 id="design--workflow">Design &#x26; Workflow</h1>
<p>At a high level, with this setup you just write your content and push it to
git. The rest takes care of itself.</p>
<p>Here's how it works:</p>
<ol>
<li>Blog content is written as text in markdown files. I use Vim.</li>
<li>When the content is ready, code is pushed to a GitHub repository.</li>
<li>A Google Cloud Build trigger watches for commits. When one happens, it loads
the Git master branch to its temporary workspace.</li>
<li>Cloud Build loads a pre-created Pelican Docker image is from Google's
Container Registry, and executes it against the markdown files to generate
a static website's .html and .css files.</li>
<li>Cloud Build uses an rsync image to transfer the files to a Google Storage
bucket.</li>
<li>Google Storage hosts the static site files on a custom domain as a website.</li>
</ol>
<p><img src="/images/blog_workflow.png" alt="Blog architecture diagram"></p>
<hr>
<h1 id="setup-configuring-pelican-and-gcp">Setup: Configuring Pelican and GCP</h1>
<h2 id="pelican-theme">Pelican Theme</h2>
<p>Before Pelican can render the markdown files into a site worth looking at,
it needs a theme to work with.</p>
<p>The easiest way to go is to <a href="http://www.pelicanthemes.com/">select a pre-made theme.</a></p>
<p>Personally, I forked a theme then heavily modified it.
Forking the theme prevents it from changing, and lets you change things as
needed. I'd suggest creating a fork of the theme even if you won't change it.</p>
<h2 id="pelican-docker-image">Pelican Docker Image</h2>
<h3 id="containerize-pelican">Containerize Pelican</h3>
<p>Next, the pelican software needs to be containerized for Cloud Build to use it.
You can either grab an existing image, such as the one I've shared on Docker
Hub, or build your own.</p>
<p><strong><a href="/docker-pelican-image.html">How to build a Docker image for Pelican</a></strong></p>
<h3 id="push-pelican-image-to-gcr">Push Pelican Image to GCR</h3>
<p>The Pelican image needs to be in the Google Container Registry for Cloud Build
to use it. GCR is like Docker Hub, but private and not free. It's pretty
affordable.</p>
<p><strong><a href="/google-container-registry.html">Using Google Cloud Registry</a></strong></p>
<h2 id="development-environment">Development Environment</h2>
<p>Google Storage's website hosting feature is great, but it has a cache that I
haven't yet figured out how to bypass. This means that if you push a mistake to
the storage, then push a fix, the fix may not display for like an hour.</p>
<p>To get past this, using a local service for development is a nice solution.
Also, this way you're not testing your code in production.</p>
<p>You can see the utility script I made <a href="https://github.com/kylep/kyle.pericak.com/blob/master/bin/pelican-dev.sh">here</a>,
but basically you just run a local Pelican image, then run <code>pelican</code> against
your content files with <code>--listen</code> and <code>--autoreload</code>.</p>
<p><strong><a href="/pelican-dev-environment.html">Pelican Website: Local Development Environment</a></strong></p>
<h2 id="cloud-build">Cloud Build</h2>
<p>Google Cloud Build is the automation framework used to watch for changes
committed to github, then transform the content files into a website and save
them to Google Cloud Storage.</p>
<p>Configure Cloud Build to watch for commits to the master branch of the blog
content repository, then run the pelican and rsync jobs against it.</p>
<p><strong><a href="/google-cloud-build.html">Google Cloud Build: Automatically Deploy Changes from GitHub</a></strong></p>
<h2 id="google-storage-web-hosting">Google Storage Web Hosting</h2>
<p>At this point, you've written your content, converted it into web files, and
synchronized those files with Google Cloud Storage. To make the website
accessible, you need to configure Google Cloud Storage to host the content as
a website. This step is also where you point your custom domain name at the new
site.</p>
<p><strong><a href="/google-cloud-storage-website.html">Google Cloud Storage: Static Website Hosting</a></strong></p>
<h1 id="secure-the-site-with-https">Secure the site with HTTPS</h1>
<p>These days there's really no good excuse to not have HTTPS on your site. On
a self-hosted site I usually use <a href="https://letsencrypt.org/">LetsEncrypt</a>, but
for this static site instead I've used the built-in HTTPS feature of
CloudFlare's free CDN solution.</p>
<p><strong><a href="/cloudflare-https.html">Using Cloudflare to provide HTTPS to an HTTP static site</a></strong></p>


Kyle Pericak

"It works in my environment"

Categories

Tags