Skip to main content

Obscene ansible runner

Project description

Bigsudo is an opinionated command line wrapper to ansible-playbook.

You must have ansible-playbook command installed for bigsudo to work!


It accepts as first argument: role name, path or url, or playbook path or url:

bigsudo # download role and run tasks/main.yml on localhost

bigsudo update # do tasks/update.yml
bigsudo user@host update # do tasks/update.yml on host
bigsudo @host update # with current user
bigsudo @host update foo=bar # custom variable
bigsudo {"foo":"bar"} # also accepts json without space
bigsudo -v # forwards any ansible-playbook argument

Note that bigsudo will automatically call ansible-galaxy install on requirements.yml it finds in any role, recursively on each role that it got galaxy to install. This means that yourlabs.docker/requirements.yml will also be installed by bigsudo if your repo has this requirements.yml:

- src: git+

How command line parsing works

Three golden rules:

  • Bigsudo runs with --become by default (well, it’s “bigsudo”), to avoid this, pass --nosudo. This is just because personnaly I am root and forget --become a lot more often than I need --nosudo.

  • Bigsudo will take bigsudo arguments first, they don’t start with a dash, they are either strings without = which means they are positionnal arguments to bigsudo Python functions, either strings with = which means they are keyword arguments to bigsudo commands.

  • From the point where an argument starts with a dash, all arguments are forwarded to ansible. You cannot pass a bigsudo argument after passing an argument that starts with a dash.

As such, these two calls are equivalent:

bigsudo yourlabs.fqdn -e foo=bar
bigsudo yourlabs.fqdn foo=bar

But that will not work:

bigsudo yourlabs.fqdn -v foo=bar

Because it will generate that command in which ansible will look for foo=bar playbook:

ansible-playbook -v foo=bar ...

Bigsudo will always print out generated ansible-playbook command lines anyway.

Continuous Deployment with Gitlab-CI

Using gitlab-ci or drone-ci you can define multiline env vars, ie a with $STAGING_HOST=deploy@yourstaging and json string for $STAGING_VARS:

  "security_salt": "yoursecretsalf",
  "mysql_password": "...",
  // ....

Then you can define a staging deploy job as such in .gitlab-ci.yml:

image: yourlabs/python

# example running tasks/update.yml, using the repo as role
script: bigsudo . update $staging_host $staging_vars

# example running playbook update.yml
script: bigsudo ./update.yml $staging_host $staging_vars

This chapter describes the steps to setup the following deploy job in your .gitlab-ci.yml:

  image: yourlabs/python
  stage: deploy

  - mkdir -p ~/.ssh; echo $staging_key > ~/.ssh/id_ed25519; echo $staging_fingerprint > ~/.ssh/known_hosts; chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
  - bigsudo . $staging_host --extra-vars=$staging_vars

    refs: [master]

    name: staging

Create an ed25519 deploy key with the following command:

ssh-keygen -t ed25519 -a 100 -f deploy.key

Upload the deployment key to your target:

ssh-copy-id -i deploy.key

Add it to the enviromnent variable $staging_key

cat deploy.key

Also add your host fingerprint in $staging_fingerprint:


Add all the variables you need for your tasks in the $staging_vars env var as a JSON dict, as described in the previous chapter.

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

bigsudo-1.1.0.tar.gz (10.6 kB view hashes)

Uploaded source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page