This is one in a series of posts about the Akamai 2018 Spring Release. For an overview of the Spring Release, see our post here.
Today with the 2018 Spring Release, we’re announcing Akamai CLI 1.0, which adds many highly-requested features, as well as several we came up with ourselves.
A project is only as successful as its documentation. That’s why we’ve released full and complete documentation for Akamai CLI 1.0, including installation, usage documentation, and a package directory. Check it out here.
Your Akamai CLI toolkit is only as useful as the packages you install. To help you find the packages you want, we’ve added a package search, as well as the ability to list all available packages. Here’s a quick look at the search functionality:
To search for packages, use
akamai search followed by the search terms; results are ranked by closest match. To list all available packages, use the new
--remote flag for
Currently, only official Akamai packages are included. We’ll be adding unofficial third-party packages soon.
One of the most requested features is support for auto-complete:
We’ve added auto-complete support for both bash and zsh shells. Calling either
akamai --bash or
akamai --zsh will display appropriate instructions for installing the auto-complete. To enable auto-completion, add either
eval "$(/Users/dshafik/bin/akamai --bash)" to your
.bash_profile file, or
eval "$(/Users/dshafik/bin/akamai --zsh)" to your
Once done, the tab key will either print possible commands or flags, or it will auto-complete the command or flag currently being typed.
Auto-complete works for package commands that opt-in to support (e.g., Purge and FastDNS). Details on how to do that can found in CLI documentation.
Akamai CLI 0.5 introduced a new configuration file, stored in
$AKAMAI_CLI_HOME/.akamai-cli/config. This configuration file—which is INI format—is used to store many CLI preferences, and can also be utilized by packages to store their own configurations.
All previous preferences (e.g. whether to enable auto updates) have been migrated to this new configuration. Additionally, we now store a flag if you choose not to install to PATH, rather than asking you every time you execute the command.
Alongside the configuration, we’ve added a new command,
akamai config, which allows you to set and retrieve individual values, list all values (optionally, within a given configuration section), and delete values. Full details can be found by running
akamai help config.
Anonymous Opt-In Metrics
In order to improve our ability to focus our resources on the right things, we’ve added some simple, anonymous opt-in metrics which are submitted to Google Analytics for review.
We recognize that this type of tracking is not desired by some, so we’ve done our best to make this as transparent as possible (source code). The first time you run this version of Akamai CLI, it will request you to opt-in. If you choose “no”, we will never track anything. If you choose “yes”, a random UUID is generated as a client ID, which can be used to group together all metrics sent by your particular client, but that cannot be traced back to you. Additionally, we’ve enabled IP Anonymization within Google Analytics to further ensure that you cannot be identified.
Currently, we track the following events:
- Akamai CLI upgrades with success/fail status, and from/to versions.
- Akamai CLI auto-upgrades with success/fail status, and from/to versions.
- Package installation with URL and success/fail status (only for packages in public Github repositories).
- Package uninstallation with command name and success/fail.
- A single ping during first run (after you choose to enable diagnostics).
- A single daily ping (similar to auto-upgrade checking, if it has been at least 24 hours since you last executed the Akamai CLI binary).
If you want to see exactly where, when, and what we track, you can easily search the repository for calls to the
Support for Local Repositories
We noticed that when users are developing packages, the ability to install from our local repository was missing. So we’ve added support for GitHub’s file:// protocol. To install a local repository, use
akamai install file:///path/to/the/repo. You can then keep it up-to-date with newly committed changes using
akamai update, just like any other package.
Since our initial release, we’ve also fixed 29 bugs, including improved support for Microsoft Windows, the ability to install multiple instances, and better support for Python 2.7.
akamai install(and then added
getback as an alias).
- Added a first-run/onboarding experience.
- Published to Homebrew for macOS users.
- Added support for package uninstall, and installing/updating/uninstalling multiple packages at once.
- Added a
akamai installthat will automatically install binaries if they are available when installing from source fails.
- Added a global
--proxyflag that takes the same values as the standard
http(s)_proxy) environment variables and forwards it on to sub-commands.
Alongside Akamai CLI 1.0, we’re also announcing several new and upcoming packages that will be available over the coming weeks:
- Akamai CLI for AppSec
- Akamai CLI for Network Lists & WAF
- Akamai CLI for Certificates
- Akamai CLI for FastDNS
- Akamai CLI for API Gateway
Including these new packages and the six we released previously, we now have over 20 packages available or in development across Akamai. We will be releasing further information on each of these new packages over the coming weeks, so stay tuned.
With the release of Akamai CLI 1.0, we are now committed (per Semantic Versioning) to backward compatibility until version 2.0. Our primary focus is to continue to release more packages to meet your needs, in order to make using and integrating with Akamai easier and faster.
Have a package or feature request? Find a bug? Submit an issue!
If you don’t yet have Akamai CLI installed, follow the installation instructions here (available for macOS, Linux, and Windows).