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)
| 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.