Documents simpler upgrade testing workflow

Tracks changes in the provisioning/testing logic:

  * Removes maintenance of the custom VM images
  * Uses Molecule to manage prod VMs
  * Removes use of `vagrant` (prefer `molecule`)

docs/development/apparmor_profiles.rst

@@ -3,8 +3,8 @@ Generating AppArmor Profiles for Tor and Apache
 
 .. code:: sh
 
-    vagrant up /staging$/
-    vagrant ssh app-staging
+    make staging
+    molecule login -s libvirt-staging-focal -h app-staging
     sudo su
     cd /var/www/securedrop
 

docs/development/release_management.rst

@@ -323,8 +323,6 @@ Release Process
    <https://support.freedom.press>`_ are notified about the release.
 #. Make sure that version string monitored by FPF's Icinga monitoring system
    is updated by the infrastructure team.
-#. Update the upgrade testing boxes following this process:
-   :ref:`updating_upgrade_boxes`.
 
 Post-Release
 ------------

docs/development/upgrade_testing.rst

@@ -9,15 +9,10 @@ existing system. This document explains how to work with this scenario to test
 features that make potentially release-breaking changes such as database
 schema updates.
 
-The Molecule upgrade scenario sets up a predefined staging Securedrop virtual
-environment using Vagrant boxes built with the latest application release.
-It also creates a virtualized APT repository, and modifies
-the SecureDrop environment to use this APT repository instead of the FPF main
-repo at https://apt.freedom.press/.
-
-You can use this scenario to test the upgrade process, using using either
-locally-built .debs or packages from the FPF test repo at
-https://apt-test.freedom.press/. Both options are described below.
+The Molecule upgrade scenario sets up a local apt server, to imitate
+how new package versions will be installed in production. You'll need
+to use a virtualized Admin Workstation to configure the base server VMs
+with the current stable version, prior to testing the upgrade.
 
 .. note:: The upgrade scenario uses QEMU/KVM via Vagrant's libvirt provider.
    If you haven't already done so, you'll need to set up the libvirt provider
@@ -28,102 +23,74 @@ https://apt-test.freedom.press/. Both options are described below.
 Upgrade testing using locally-built packages
 --------------------------------------------
 
-First, build the app code packages and create the environment:
+First, create prod VMs for use with the current stable version.
+These machines will be upgraded with newer, locally built deb packages
+in a subsequent step.
 
 .. code:: sh
 
- make build-debs
- make upgrade-start
-
-The playbook will return the source interface Onion address. You can use this to
-check the application version displayed in the source interface footer.
-Alternatively, you can log into the *Application Server* VM and check the deployed
-package version directly:
+  molecule create -s libvirt-prod-focal
 
-.. code:: sh
-
-   molecule login -s upgrade -h app-staging
+Next, boot your Admin Workstation VM and proceed with a full install
+on these VMs, via ``./securedrop-admin install``. Make sure to run
+``./securedrop-admin tailsconfig`` to finalize the installation.
 
-From the *Application Server*:
+Next, build the app code packages and create the environment:
 
 .. code:: sh
 
-   apt-cache-policy securedrop-config
-
-The installed package version should match the latest release version.
+ make build-debs
+ make upgrade-start
 
-To perform an upgrade using the virtualized APT repository, log out of the
-*Application Server* and run the Molecule side-effect action:
+The playbook will create a local apt server on your host machine, and
+serve the locally built deb packages from that local endpoint.
+In order to add the local apt server to the VMs, switch back to
+the Admin Workstation and run:
 
 .. code:: sh
 
-   make upgrade-test-local
-
-This will upgrade the SecureDrop packages on the *Application* and
-*Monitor Servers*, using your locally-built packages and apt VM instead of the
-FPF production apt repository.
-
-You can verify that the application version has changed either by checking the
-source interface's footer or directly on the *Application Server* as described
-above.
-
-.. _upgrade_testing_apt:
-
-Upgrade testing using apt-test.freedom.press
---------------------------------------------
+   source admin/.venv3/bin/activate
+   cd install_files/ansible-base
+   ansible-playbook -vv --diff securedrop-apt-local.yml
 
-You can use the upgrade scenario to test upgrades using official release
-candidate packages from the FPF test APT repository. First,
-create the environment:
+Both VMs will now be able to be able to view newer, locally built packages.
+To confirm:
 
 .. code:: sh
 
-   make upgrade-start-qa
+   molecule login -s libvirt-prod-focal -h app-prod
 
-Then, log into the *Application Server*:
+From the *Application Server*:
 
 .. code:: sh
 
-   molecule login -s upgrade -h app-staging
-
-From the *Application Server*:
+   apt-cache-policy securedrop-app-code
 
-.. code:: sh
+The installed package version should match the latest stable version,
+but the locally built package with higher version should be available
+as a candidate for installation.
 
-   sudo apt-get update
-   apt-cache policy securedrop-config
+Upgrade testing using apt-test.freedom.press
+--------------------------------------------
 
-The installed package version should match the current release version.
-To install the latest packages from the apt-test proxy:
+You can also evaluate packages on the https://apt-test.freedom.press/
+repository. As above, create prod VMs and configure them via the
+Admin Workstation. After installation, you can enable the ``apt-test``
+repo like so:
 
 .. code:: sh
 
-   make upgrade-test-qa
+   source admin/.venv3/bin/activate
+   cd install_files/ansible-base
+   ansible-playbook -vv --diff securedrop-qa.yml
 
-Log back into the *Application Server*, and repeat the previous commands:
+Then, log into the *Application Server*:
 
 .. code:: sh
 
-   sudo apt-get update
+   molecule login -s libvirt-prod-focal -h app-prod
    apt-cache policy securedrop-config
 
-Navigate to the Source Interface URL again, and confirm you see the upgraded
-version in the footer. Then proceed with testing the new version.
-
-.. _updating_upgrade_boxes:
-
-Updating the base boxes used for upgrade testing
-------------------------------------------------
-
-When a new version of SecureDrop is released, we must create and upload
-new VM images, to enable testing against that base version in future upgrade
-testing. The procedure is as follows:
-
-1. ``make clean`` to remove any previous artifacts (which would also be pushed)
-#. ``git checkout <version>``
-#. ``make vagrant-package``
-#. ``cd molecule/vagrant-packager && ./push.yml`` to upload to S3
-#. Commit the local changes to JSON files and open a PR.
-
-Subsequent invocations of ``make upgrade-start`` will pull the latest
-version of the box.
+The installed package version should match the latest stable version,
+with the locally built package of a higher version available
+as a candidate for installation.

docs/development/virtual_environments.rst

@@ -121,16 +121,7 @@ Production
 
 This is a production installation with all of the system hardening active, but
 virtualized, rather than running on hardware. You will need to
-:ref:`configure prod-like secrets<configure_securedrop>`, or export
-``ANSIBLE_ARGS="--skip-tags validate"`` to skip the tasks that prevent the prod
-playbook from running with Vagrant-specific info.
-
-You can provision production VMs from an Admin Workstation (most realistic),
-or from your host. If your host OS is Linux-based and you plan to use an Admin
-Workstation, you will need to switch Vagrant's default virtualization provider
-to  ``libvirt``.
-
-Instructions for both installation methods follow.
+use a virtualized Admin Workstation in order to provision these machines.
 
 .. _libvirt_provider:
 
@@ -221,9 +212,6 @@ Set the default Vagrant provider to ``libvirt``:
    export VAGRANT_DEFAULT_PROVIDER=libvirt
 
 
-.. note:: To explicitly specify the ``libvirt``  provider below, use the command
-   ``vagrant up --provider=libvirt /prod/``
-
 Convert Vagrant boxes to libvirt
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Convert the VirtualBox images for Focal from ``virtualbox`` to ``libvirt`` format:
@@ -250,7 +238,7 @@ Once you're prepared the *Admin Workstation*, you can start each VM:
 
 .. code:: sh
 
-  vagrant up --no-provision /prod/
+  molecule create -s libvirt-focal-prod
 
 At this point you should be able to SSH into both ``app-prod`` and ``mon-prod``.
 From here you can follow the :ref:`server configuration instructions
@@ -278,49 +266,3 @@ After install you can configure your Admin Workstation to SSH into each VM via:
 .. code:: sh
 
   ./securedrop-admin tailsconfig
-
-Install from Host OS
-~~~~~~~~~~~~~~~~~~~~
-
-If you are not virtualizing Tails, you can manually modify ``site-specific``,
-and then provision the machines. You should set the following options in
-``site-specific``:
-
-.. code:: sh
-
-  ssh_users: "vagrant"
-  monitor_ip: "10.0.1.5"
-  monitor_hostname: "mon-prod"
-  app_hostname: "app-prod"
-  app_ip: "10.0.1.4"
-
-Note that you will also need to generate Submission and OSSEC PGP public keys,
-and provide email credentials to send emails to. Refer to
-:ref:`this document on configuring prod-like secrets<configure_securedrop>`
-for more details on those steps.
-
-To create the prod servers, run:
-
-.. code:: sh
-
-   vagrant up /prod/
-   vagrant ssh app-prod
-   sudo -u www-data bash
-   cd /var/www/securedrop/
-   ./manage.py add-admin
-
-A copy of the Onion URLs for Source and Journalist Interfaces, as well as
-SSH access, are written to the Vagrant host's ``install_files/ansible-base``
-directory, named:
-
-* ``app-sourcev3-ths``
-* ``app-journalist.auth_private``
-* ``app-ssh.auth_private``
-* ``mon-ssh.auth_private``
-
-SSH Access
-~~~~~~~~~~
-
-By default, direct SSH access is not enabled in the prod environment. You will need to log
-in over Tor after initial provisioning or set ``enable_ssh_over_tor`` to "false"
-during ``./securedrop-admin tailsconfig``.