Skip to main content

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

Features

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

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

bigsudo role.name update # do tasks/update.yml
bigsudo role.name user@host update # do tasks/update.yml on host
bigsudo role.name @host update # with current user
bigsudo role.name @host update foo=bar # custom variable
bigsudo role.name {"foo":"bar"} # also accepts json without space
bigsudo role.name --become # 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+https://yourlabs.io/oss/yourlabs.docker

The gotcha is that you cannot pass values to a short-written argument (because it’s my opinion that ansible commands are more readable as such), ie:

# works:
$ ./example/playbook.yml --tags=foo
ansible-playbook --tags=foo -c local -i localhost, -e apply_tasks='["main"]' ./example/playbook.yml

# does NOT work: parser doesn't detect that foo is the value of -t:
$ ./example/playbook.yml -t foo
ansible-playbook -t -c local -i localhost, -e apply_tasks='["foo"]' ./example/playbook.yml

# does NOT work: parser doesn't detect that foo is the value of --tags:
$ ./example/playbook.yml --tags foo
ansible-playbook --tags -c local -i localhost, -e apply_tasks='["foo"]' ./example/playbook.yml

Using gitlab-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

Continuous Deployment with Gitlab-CI

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

deploy-staging:
  image: yourlabs/python
  stage: deploy

  script:
  - 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

  only:
    refs: [master]

  environment:
    name: staging
    url: https://staging.example.com

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 user@staging.host

Add it to the enviromnent variable $staging_key

cat deploy.key

Also add your host fingerprint in $staging_fingerprint:

ssh-keyscan staging.host

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.

Metadata

Release files for bigsudo 0.2.0.post10

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for bigsudo 0.2.0.post10
File Size Uploaded Provenance Actions
bigsudo-0.2.0.post10.tar.gz 2.7 kB Without provenance Details for bigsudo-0.2.0.post10.tar.gz

Release files / bigsudo-0.2.0.post10.tar.gz

Download URL bigsudo-0.2.0.post10.tar.gz
Size 2.7 kB
Tags Source
SHA-256 checksum
How to use checksums
11a0bf94db1f59c2262c9e147b5a262fa45f6b9bc6ae543e0a0d52de3b71d790
BLAKE2b-256 checksum
How to use checksums
31ced24667bfc45a31e12566d8589955a652479ec59b9b22a05ab5225b14b02a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/1.13.0 pkginfo/1.5.0.1 requests/2.22.0 setuptools/40.6.2 requests-toolbelt/0.9.1 tqdm/4.32.1 CPython/3.6.8

Security for bigsudo 0.2.0.post10

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page