gcloudwrap 1.0.3

gcloudwrap

gcloudwrap provides a wrapper around the Google API client to help you manage your Google cloud (i.e. its ‘compute’ component). The original client provides all the needed functionality and gcloudwrap adds little in terms of extras. However, we found it easier to have a thin wrapper around the cloud management to give us a domain language closer to the tasks we had to repeatedly execute.

We initially found it hard to develop using original Google API client since it lacked type annotations and its dynamic approach to object creation allowed no code inspection in an IDE such as PyCharm. Since scripts involving cloud management usually take longer to execute, we found our development iterations to be fairly long and often broke due to minor errors related to incorrect types. Therefore, we added type annotations so that the static analyzer (such as mypy) would panic and catch the type errors early. This substantially facilitated the development of the deployment scripts.

Mind that we have not wrapped all of Google Compute API. We focused only on the parts necessary for the deployment. Please create an issue if you would like more functionality to be wrapped.

Scenarios

Related Projects

• https://github.com/google/google-api-python-client/ – original Google API client whih we wrapped

• https://googlecloudplatform.github.io/google-cloud-python/ – client for Google Cloud Platform services; it still lacked Compute support at the time we started developing gcloudwrap (2018-05-01)

• https://pypi-hypernode.com/project/gwrappy/ – user-friendly wrapper for Google APIs. This wrapper covers way more services that we had in mind. Since it does not focus on the deployment, it did not match with our idea to have a simple deployment language.

• https://libcloud.readthedocs.io/en/latest/index.html – abstracts differences between cloud providers and provides a unified API. If you plan to use different cloud providers, this is a better alternative. In case you only want to use Google cloud, we found that such an abstraction library introduces unnecessary complexity.

Usage

We tried to follow the naming of the API as much as possible. The definition and description of the API can be found here: Google Compute API. However, we complied to Python naming convention, and renamed all camelCase arguments into snake_case.

The following code snippet shows a common deployment which creates an instance with a persistent disk and a reserved external IP address. The instance is tagged with ‘default-allow-http’ to open a HTTP port in its firewall. Finally, we authorize a public SSH key with the instance.

import pathlib

import gcloudwrap

instance = 'some-instance'
address = 'some-address'
disk = 'some-persistent-disk'
device_name = 'persistency'

service_account = 'some-service-account@some-project-221984.iam.gserviceaccount.com

public_ssh_key = pathlib.Path(
    '/some/path/to/ssh/id_rsa.pub').read_text()

gce = gcloudwrap.Gce()

gce.addresses.insert(name=address)
static_ip = gce.addresses.static_ip(
    address=address)

gce.disks.insert(
    name=disk,
    disk_type='pd-standard',
    size_gb=5)

gce.instances.insert(
    name=instance,
    machine_type='f1-micro',
    address=static_ip,
    service_account=service_account)

gce.instances.attach_disk(
    instance=instance,
    disk=disk,
    device_name=device_name)

# open up HTTP port
tags = gce.instances.tags(instance=instance)
tags.items.add('default-allow-http')
gce.instances.set_tags(
    instance=instance, tags=tags)

# authorize the SSH key
keys = gcloudwrap.SSHKey(
    user='some-user',
    public_key=public_key)

metadata = gce.instances.metadata(instance=instance)
metadata.set_ssh_keys(keys=[key])

gce.instances.set_metadata(
    instance=instance,
    metadata=metadata)

# format the persistent disk and mount it
ssh = gce.instances.ssh(
    instance=instance,
    user="some-devop-user")

operator = gcloudwrap.Operator(call_fn=ssh.call)

operator.format_disk(
    device_name=device_name)

operator.mount_disk(
    device_name=device_name,
    path=pathlib.Path('/mnt/disks/persistency'))

Sometimes it is convenient to store the list of authorized SSH keys in a file and re-use this list when deploying the instance. We provide a shortcut function gcloudwrap.ssh_keys_from_file to achieve that:

import gcloudwrap

instance = 'some-instance'
keys_path = '/path/to/some/keys.txt'

keys = gcloudwrap.ssh_keys_from_file(
    path=keys_path,
    default_user='some-default-user')

metadata = gce.instances.metadata(instance=instance)
metadata.set_ssh_keys(keys=keys)

gce.instances.set_metadata(
    instance=instance,
    metadata=metadata)

Installation

• Create a virtual environment:

python3 -m venv venv3

• Activate it:

source venv3/bin/activate

• Install gcloudwrap with pip:

pip3 install gcloudwrap

• Set up the application-default credentials

gcloud auth application-default login

Development

• Check out the repository.

• In the repository root, create the virtual environment:

python3 -m venv venv3

• Activate the virtual environment:

source venv3/bin/activate

• Install the development dependencies:

pip3 install -e .[dev]

• We provide a set of live tests. You need to set up your environment such that the credentials can be directly inferred by the tests. Apart from the credentials, you can also use the following environment variables:

  • TEST_GCLOUDWRAP_SERVICE_ACCOUNT to specify the service account attached to the instances created during the test. If unspecified, default service account of the GCE project is used.

  • TEST_GCLOUDWRAP_PREFIX to specify the prefix of all the created Google cloud resources; if not specified, equals “test-gcloudwrap”

  • TEST_GCLOUDWRAP_SSH_PUBLIC_KEY_PATH to specify the path to the SSH public key; if not specified, equals ~/.ssh/id_rsa.pub (where “~” is expanded to the user home directory)

  Mind that the live tests will use Google Cloud resources for which you will be billed. Always check that no resources are used after the tests finished so that you don’t incur an unnecessary cost!

• We use tox for testing and packaging the distribution. Assuming that the virtual environment has been activated and the development dependencies have been installed, run:

tox

• We also provide a set of pre-commit checks that lint and check code for formatting. Run them locally from an activated virtual environment with development dependencies:

./precommit.py

• The pre-commit script can also automatically format the code:

./precommit.py  --overwrite

Versioning

We follow Semantic Versioning. The version X.Y.Z indicates:

• X is the major version (backward-incompatible),

• Y is the minor version (backward-compatible), and

• Z is the patch version (backward-compatible bug fix).