Sykle is a cli tool for calling commonly used commands in docker-compose projects.
dev
, test
, and prod
python 3.4
(may work on earlier versions of 3, but not tested. Plugins do NOT work in python version 2.7)docker
(locally and on deployment target)docker-compose
(locally and on deployment target)ssh
scp
pip install git+ssh://git@github.com/typecode/sykle.git --upgrade
python3
installation, you should use pip3pip3 install git+ssh://git@github.com/typecode/sykle.git --upgrade
Because sykle tries to make as few assumptions about your project as possible, you'll need to declaratively define how your app should run via static configuration files
Sykle uses 4 different docker-compose configurations:
docker-compose.yml
for developmentdocker-compose.test.yml
for testingdocker-compose.prod-build.yml
for building/deploying productiondocker-compose.prod.yml
for running productionThese separate configurations allow you to tweak how your projects run in those 4 standard scenarios, and helps ensure that there no conflicting assumptions between environments.
In addition to your docker-compose
files, you'll need a .sykle.json
. An example detailing how to build a config file can be viewed from the cli via syk config
Usage instructions can be viewed after installation with syk --help
This will not show any info for plugins. In order to view installed plugins, run syk plugins
. To view help for a specfic plugin, run syk <plugin_name> --help
.
Prior to sykle, the predominate pattern at typecode was to create a ./run.sh
file with a list of commands. For convenience, if a ./run.sh
file is found, sykle will try to run commands through ./run.sh
before running through sykle.
Once you have configured deployments, you can connect to them using syk --deployment=<deployment> ssh
. Sykle does not currently allow you pass any options when sshing into a remove machine and relies on ~/.ssh/config
to pass along the correct credentials. An example config is shown below, and more details on ssh config can be found here.
Host ec2-3-95-177-93.compute-1.amazonaws.com
User ubuntu
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/flir-pb.pem
Unittests (that test sykle) can be run via python setup.py test
There are two types of plugins: global plugins and local plugins.
Local plugins allow you to create project specific commands. If you have a command or series of commands that you run frequently for a project that are more complicated than an alias, it might make sense to create a local plugin.
To create a local plugin:
.sykle-plugins/
directory in the root of your project (.sykle-plugins/
should be in same directory as .sykle.json
)__init__.py
file to .sykle-plugins/
.sykle-plugins/
(EX: .sykle-plugins/my_plugin.py
)Example
"""my_plugin
Usage:
syk my_plugin <str>
Options:
-h --help Show help info
Description:
my_plugin prints out the string passed in as an argument
"""
from docopt import docopt
from sykle.plugin_utils import IPlugin
class Plugin(IPlugin): # class MUST be named Plugin
NAME = 'my_plugin' # this attribue is required
REQUIRED_VERSION = '0.3.0' # this attribute is option (specifies lowest version of sykle required)
# this is what gets invoked when you run `syk my_plugins hi`
def run(self):
args = docopt(__doc__)
str = args.get('<str>')
# self.sykle <- sykle instance
# self.sykle_config <- config used by sykle instance
# self.config <- any config specific to this plugin
print(str)
Note that syk
is present in the docopt usage definition before the plugin command. This is required.
If you defined your plugin correctly, you should be able to see listed when calling syk plugins
Global plugins are the same as local plugins, but they are added to the plugins
folder of this repo and are available to anyone who installs sykle.
test
commandsinit
command to create .sykle.json
.sykle.json
~ Local plugins./run.sh
if it exists and .sykle.json
does notdocker-compose
files can/should be shared