You are browsing a read-only backup copy of Wikitech. The live site can be found at


From Wikitech-static
< Analytics‎ | Systems
Revision as of 15:24, 2 June 2021 by imported>Ottomata (→‎Creating a new Airflow Instance)
Jump to navigation Jump to search

WIP documentation page.

See also

Airflow Instances


Airflow instance owned by the Data / Analytics engineering team.



Airflow test instance owned by the Data / Analytics engineering team.

Host an-test-coord1001.eqiad.wmnet
Web UI Port 8600
Dags refinery/airflow/dags

SSH Tunnel to Web UI:

 ssh -t -N -L8600: an-test-coord1001.eqiad.wmnet




Creating a new Airflow Instance

In this example, we'll be creating a new Airflow instance named 'test'.

Create the Airflow MySQL Database

You'll need a running MariaDB instance somewhere. If your MariaDB instance is replicated, you'll need to run the GRANT statement on the replicas as well.

CREATE DATABASE airflow_test;
CREATE USER 'airflow_test' IDENTIFIED BY 'password_here';
GRANT ALL PRIVILEGES ON airflow_test.* TO 'airflow_test';

Make sure your MariaDB config sets explicit_defaults_for_timestamp = on. See:

Configure the Airflow instance in Puppet

Add the profile::airflow class to your node's role in Puppet and configure the Airflow instance(s) in your role's hiera.

Let's assume we're adding this instance in a role class role::airflow::test.

class role::airflow::test {
    include ::profile::airflow
    # profile::kerberos::keytabs is needed if your Airflow
    # instance needs to authenticate with Kerberos.
    # You'll need to create and configure the keytab for the Airflow instance's
    # $service_user we'll set below.
    include ::profile::kerberos::keytabs

Then, in hieradata/role/common/airflow/test.yaml:

# Set up airflow instances.
  # airflow@test instance.
    # Since we set security: kerberos a keytab must be deployed for the service_user.
    service_user: test_user
    service_group: test_group
   # Set this to true if you want enable alerting for your airflow instance.
    monitoring_enabled: false
    # Configuration for /srv/airflow-test/airflow.cfg
    # Any airflow configs can go here. See:
        security: kerberos # you don't need to set this if you don't use Kerberos.
        executor: LocalExecutor
        # This can be an ERB template that will be rendered in airflow::instance.
        # db_user and db_password params should be set in puppet private
        # in profile::airflow::instances_secrets.
        sql_alchemy_conn: mysql://<%= @db_user %>:<%= @db_password %>@my-db-host.eqiad.wmnet/airflow_analytics?ssl_ca=/etc/ssl/certs/Puppet_Internal_CA.pem

# Make sure the keytab for test_user is deployed via profile::kerberos::keytabs
  - role: 'test_user'
    owner: 'test_user'
    group: 'test_group'
    filename: 'test_user.keytab'

See Create_a_keytab_for_a_service for instructions on creating keytabs.

Note that we didn't set db_user or db_password. These are secrets and should be set in the operations puppet private repository in the hiera variable profile::airflow::instances_secrets. So, in puppet private in the hieradata/role/common/airflow/test.yaml file:

# Set up airflow instances.
  # airflow@test instance.
    db_user: airflow_test
    db_password: password_here

profile::airflow::instances_secrets will be merged with profile::airflow::instances by the profile::airflow class, and the parameters to airflow::instance will be available for use in the sql_alchemy_conn as an ERb template.

Once this is merged and applied, the node with the role::airflow::test will run the systemd services airflow-scheduler@test, airflow-webserver@test, airflow-kerberos@test, as well as some 'control' systemd services airflow@test and airflow that can be used to manage the Airflow test instance.