Giter Site home page Giter Site logo

hokusai's Introduction

HOKUSAI CircleCI

Hokusai is a Docker + Kubernetes CLI for application developers.

Hokusai "dockerizes" applications and manages their lifecycle throughout development, testing, and release cycles.

Hokusai wraps calls to Kubectl, Docker, Docker-Compose and Git with a CLI, and defines a CI workflow.

Hokusai currently only supports Kubernetes deployments on AWS, configured to pull from ECS container repositories (ECR), although other providers may be added in the future.

Why Hokusai?

At Artsy, as we began working with Kubernetes, while impressed with its design, capabilities, and flexibility, we were in need of tooling we could deliver to agile development teams that addressed the day-to-day tasks of application development, delivery, introspection and maintenance, while providing a clean and uncomplicated interface.

Transitioning teams to the Docker / Kubernetes ecosystem can be intimidating, and comes with a steep learning curve. We set out to create a Heroku-like CLI that would shepherd the application developer into the ecosystems of Docker and Kubernetes, and while introducing new tooling and concepts, outlining a clear practice for dependency management, local development, testing and CI, image repository structure, deployment and orchestration.

Installation

MacOS

We recommend installing via Homebrew:

$ brew update
$ brew tap artsy/formulas
$ brew install hokusai

If you previously installed Hokusai via an alternate installation method, you may need to force the link step.

$ brew link --overwrite hokusai

If you previously installed Hokusai via Pip, you may want to first uninstall it:

$ pip uninstall hokusai

Linux

curl -sSL https://raw.githubusercontent.com/artsy/hokusai/main/get-hokusai.sh | sudo bash

Note: This method installs Hokusai to /usr/local/bin/hokusai.

Pip

Hokusai can be installed via Pip, on MacOS or Linux. If you do so, please first go through Pyenv, Python, and Virtualenv steps.

Python 3.7+ is required.

pip install hokusai

Note: If Pip fails at upgrading your system Python packages, try:

pip install hokusai --ignore-installed

Docker

We also maintain Hokusai Docker images for running Hokusai in Docker.

Github

Release artifacts are available on Github.

AWS S3

Release artifacts are also available in AWS S3. You can use this convenience script or Curl to fetch them.

A note on Python 2.x

Hokusai currently supports Python 3.7+ only. The last version that supported Python 2.x was v0.5.18.

Setup

We assume that your org admin has already set up a Kubernetes cluster and an AWS infrastructure, and that your local environment has Git, Docker, and Docker-Compose installed. Perform the following steps to get Hokusai working:

  1. Ensure your org admin has completed the steps mentioned in Administering Hokusai.

  2. Configure your local environment with AWS credentials.

  3. Run hokusai configure command.

  4. Optionally, enable Bash autocompletion:

    eval "$(_HOKUSAI_COMPLETE=source hokusai)"
    

Getting Started

Once Hokusai is configured, you can start using it on a project. Please see Getting Started.

Command Reference

A full command reference can be found in Command Reference.

Review Apps

Hokusai can be used to simplify the process of spinning up a "review app" instance of your project, based on a feature branch or pull request.

Full details are in the Review App reference.

Hokusai Files

A descripton of all the files used by Hokusai.

Developing Hokusai

To work on Hokusai itself, please set up:

Pyenv

We recommend using Pyenv to install the correct version of Python. For a tutorial of Pyenv, see this guide.

When installing on MacOS, please make sure to use brew-installed openssl and readline libraries, and xcode-installed zlib library. And make sure these libraries are correctly linked. Like so:

brew install openssl readline zlib

echo 'export PATH="/usr/local/opt/[email protected]/bin:$PATH"' >> ~/.bash_profile
echo 'export LDFLAGS="-L/usr/local/opt/[email protected]/lib"' >> ~/.bash_profile
echo 'export CPPFLAGS="-I/usr/local/opt/[email protected]/include"' >> ~/.bash_profile
echo 'export PKG_CONFIG_PATH="/usr/local/opt/[email protected]/lib/pkgconfig"' >> ~/.bash_profile

Python

Hokusai is currently tested on Python 3.10 so we recommend using that Python version.

If you use Pyenv to install Python, you should see an output similar to this:

$ pyenv install 3.10
python-build: use [email protected] from homebrew
python-build: use readline from homebrew
Downloading Python-3.10.13.tar.xz...
-> https://www.python.org/ftp/python/3.10.13/Python-3.10.13.tar.xz
Installing Python-3.10.13...
python-build: use tcl-tk from homebrew
python-build: use readline from homebrew
python-build: use ncurses from homebrew
python-build: use zlib from xcode sdk
Installed Python-3.10.13 to /Users/jxu/.pyenv/versions/3.10.13

With the desired Python version installed, activate it globally:

pyenv global 3.10

Note: If you want to create a PyInstaller distribution, Python must be installed with development libraries. Use the environment variable PYTHON_CONFIGURE_OPTS="--enable-framework" on Darwin and PYTHON_CONFIGURE_OPTS="--enable-shared" on Linux when running pyenv install.

Virtualenv

We recommend using a virtual environment to isolate Hokusai's dependencies from that of other projects on your local environment.

The Pyenv install comes with pyenv-virtualenv which can be used to create virtual environments.

Poetry

Use Poetry to install Hokusai's dependencies as well as Hokusai itself in editable mode. Please see this guide for working with Poetry.

Install Poetry:

pip install --upgrade pip
pip install poetry

Install dependencies and Hokusai in editable mode:

poetry install

To update dependencies:

poetry lock

Testing

Install Minikube

Minikube is used for integration tests.

brew install minikube
minikube start --kubernetes-version=<version of your Kubernetes clusters, example: v1.2.3>

Run tests

To run unit tests:

make test

To run integration tests:

make integration-local

Only specific modules, TestClasses, or even methods:

python -m unittest test.unit.test_module.TestClass.test_method

Tip: Set DEBUG=1 environment variable to print boto logging

Distributing Hokusai

Beta Release

Merging a branch into main automatically creates a beta version useful for testing. A script that runs in CI automatically generates a Beta version number and writes it into VERSION file. The version number is based on the combination of the latest canonical version found in RELEASE_VERSION file and the latest Git commit in main branch. VERSION file in version control has just a dummy number (e.g. 999.999.999).

To install the beta:

MacOS

$ brew uninstall hokusai
$ brew uninstall hokusai-beta
$ brew update
$ brew tap artsy/formulas
$ brew install hokusai-beta

Linux

curl -sSL https://raw.githubusercontent.com/artsy/hokusai/main/get-hokusai.sh | sudo bash -s beta

Official Release

To create an official release, such as v1.2.3, perform the following:

  • Create a branch named prepare-v1.2.3 and make the following changes:

  • Open a PR to merge main into release. Please see past PRs for example.

A CI script will copy the version in RELEASE_VERSION file to VERSION file.

The Name

The project is named for the great Japanese artist Katsushika Hokusai (1760-1849).

About Artsy

This project is the work of engineers at Artsy, the world's leading and largest online art marketplace and platform for discovering art. One of our core Engineering Principles is being Open Source by Default which means we strive to share as many details of our work as possible.

You can learn more about this work from our blog and by following @ArtsyOpenSource or explore our public data by checking out our API. If you're interested in a career at Artsy, read through our job postings!

hokusai's People

Contributors

acjay avatar alloy avatar anandaroop avatar ansor4 avatar artsyjian avatar aryartsy avatar ashkan18 avatar cavvia avatar chr-tatu avatar damassi avatar dblandin avatar dependabot[bot] avatar dleve123 avatar ds300 avatar eessex avatar icirellik avatar izakp avatar jo-rs avatar joeyaghion avatar jonallured avatar mc-jones avatar mzikherman avatar ovasdi avatar pepopowitz avatar pvinis avatar saolsen avatar shaq31415926 avatar sonecabr avatar starsirius avatar zephraph avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hokusai's Issues

Gracefully fail when run with missing configuration

I had installed the dependencies and Hokusai but had skipped the hokusai configure ... step (my fault). But I got some nondescriptive errors:

➜ hokusai staging  status

Deployments
-----------------------------------------------------------
error: context "staging" does not exist
ERROR: Command 'kubectl --context staging get deployments --selector app=currents -o wide' returned non-zero exit status 1
➜  kubectl --context staging get deployments --selector app=currents -o wide
error: context "staging" does not exist

Is there an opportunity to provide more descriptive feedback, like "I couldn't connect to the cluster" or "I haven't been configured yet" or something?

`hokusai pipeline gitcompare` links are broken by default

dl@phoenix:~/src/exchange * (master)
$ cd ~/src/exchange/
dl@phoenix:~/src/exchange * (master)
$ hokusai pipeline gitcompare
https://github.com/None/exchange/compare/263816e260c013033d1bbcb27b0f54a7fd32c60a...5e4f854a52927db07cb2d1cbfe36deeb1e4a0d09
dl@phoenix:~/src/exchange * (master)
$ hokusai pipeline gitcompare --org artsy
Error: no such option: --org  Did you mean --org-name?
dl@phoenix:~/src/exchange * (master)
$ hokusai pipeline gitcompare --org-name artsy
https://github.com/artsy/exchange/compare/263816e260c013033d1bbcb27b0f54a7fd32c60a...5e4f854a52927db07cb2d1cbfe36deeb1e4a0d09
dl@phoenix:~/src/exchange * (master)
$ hokusai pipeline gitcompare --help
Usage: hokusai pipeline gitcompare [OPTIONS]

  Prints a git compare link between the tag currently deployed on production and the tag currently deployed on staging

Options:
  --git-compare-link TEXT  Python formatted string input that gets org name, project name and 2 diff sha1s, example: https://github.com/%s/%s/compare/%s...%s
  --org-name TEXT          Run a migration before deploying
  -v, --verbose            Verbose output
  -h, --help               Show this message and exit.
dl@phoenix:~/src/exchange * (master)
$ hokusai version
0.5.0

Notice the None in the URL in the first expression in the above code block.

Some related and not mutually exclusive solutions that come to mind:

  1. Make --org-name a required argument to the command,
  2. Parse the git-remote in hokusai/config.yml, if present, and build a Github compare link
    1. converting "[email protected]:artsy/exchange.git" -> "https://github.com/artsy/exchange" seems doable;
  3. Maybe make gitcompare more strict by only supporting Github for now; simplifying an implementation for (2).

cc @ashkan18 and @izakp

Circular dependency in workflow when launching a new service

I've noticed that there's a circular dependency, sort of a Catch-22 situation in our current Hokusai CI workflow when launching a new service...

So what's the Scenario? A dev has a new service ready to deploy to staging, and wants to make their first build and launch a staging stack. Hokusai sort of prefers to be run via CI, by executing the commands hokusai test -> hokusai push -> hokusai staging deploy {TAG} on merges to master.

  • hokusai push creates an image tagged {TAG} as the SHA1 of HEAD and additionally creates or updates the tag latest for that same image

  • hokusai staging deploy {TAG} creates a tag staging as a pointer to {TAG} so it can be referenced in ./hokusai/staging.yml and ensure hokusai staging create can be run without changing the current deployment. However, the tag latest needs to be present before hokusai staging create can create the staging tag and succeed. The only thing we can do now is let the first deployment fail, then run hokusai staging create. We need to do the same for production.

Creating the first image in the registry by running hokusai push locally is a workaround but not an ideal solution, as local config and environments can easily bleed into the built image.

Improve UX for roll-backs

Having tried to do this today, I don’t think the instructions are enough.

Consider this listing of images:

$ hokusai registry images

Image Pushed At           | Image Digest                                                     | Image Tags
-------------------------------------------------------------------------------------------------------------------------------
2018-09-25 02:29:41+02:00 | 6d339569a927239ffe68cbb215d4432e85f6c80d6b9ac5d83a47a0fc48de4841 | latest, a6b3494f8d96e9f12939dd5d977e32c3cf2d0078
2018-09-25 01:42:28+02:00 | a18d67a9726a49845bf6378f15266b3f3de62b6142462047c23c31a51baf456a | 002dbfd732d4d14bc65ff46159a2c996b52f9b89
2018-09-25 01:34:39+02:00 | 672e49366f86820ff00b1fd55939c5b9ffe6715d1b466b2303d08ca60ac13c7e | d942072bd9e6c9f1131fdd3f9834ca12f2f15d16
2018-09-25 01:29:23+02:00 | 33ec3a278a85a0463122901281fc5c5f2a2791bc854d80ab4ece1809fd76bc3a | 32953cd04bec83d813cd3ac8e4ae9064605f9749
2018-09-25 01:23:52+02:00 | ae040d1594189cce95aa93b8d3f37cd66bdbd838fc26a91eb94460999ddaa2b5 | 78c295a38097ea12e7e851610cee4a625e500656
2018-09-25 01:04:06+02:00 | 721645994c3423c7f27fd48c12211eab2f1c61b551484ac735a4148b6d09cf84 | production--2018-09-25--10-19-20, production, fe505b0a740f9198d1d6a71b70b604242ab380cb, staging--2018-09-24--23-04-29, staging
2018-09-24 23:20:46+02:00 | b283f4f5c874cb94b83c2e33b2bcf6b5e89a0925efc8e07f94ff63a55090d3e5 | staging--2018-09-24--21-21-26, 8c825c33a3d3b288e649bbce74ff8417a3811f14
2018-09-24 22:19:03+02:00 | d952658d2b8502d874930d8e2c86a51fb9105cb2193a4080c5974f8aabd9e965 | staging--2018-09-24--20-19-39, fe304030159fd6687c9c54d8e2f8212b6ad02eed
2018-09-24 17:13:53+02:00 | fb7090fc960b5170260bfbe498c0baab1fe3c7ba044964a2678217cb27a07d18 | f7681a0f2cb2a44bec2628045d0ed7834e5393f0, staging--2018-09-24--15-14-13
2018-09-21 11:54:28+02:00 | 95ce2867b00fdf418351bd2e7362373d6bcc9de8c6a8db982645cd119a911543 | staging--2018-09-21--09-55-03, e2344f931f66e4af0b196b737f4a8c2fef63986e
2018-09-20 23:48:10+02:00 | 296c9f56c946e96fab1b43d452debe25e143f30603f2a7266a11bdf4c721d970 | staging--2018-09-20--21-49-12, 159dcbaf2c7d5fccda2c8687a024702236080e1a
2018-09-20 23:26:02+02:00 | ff7c61511d0715372898abddadb0508447f0d23fd2ca12220381c94ebee069ed | a16de126078b5874ec402d68deba6950f0ed9f36, staging--2018-09-20--21-26-20
2018-09-20 22:43:05+02:00 | 654524bdf3c853bc54fc2548c38e38c0e6d168b7a5e4d3b87f0c9b5fd132cf45 | 4d3ef20688b8733ffb7bcc9fbb0ed298d0b692c7, staging--2018-09-20--20-43-25
2018-09-20 21:05:42+02:00 | 88662a97bbd8858e9d8660d8a68337ea9f530a9205eaa6931ed569454ae16bab | staging--2018-09-20--19-06-21, production--2018-09-20--20-38-16, production--2018-09-20--21-03-53, c18df1491160ffc26a845ef536f9a8f70a4e7560
2018-09-18 23:26:15+02:00 | dc69e17f364e4f1b9135c7048b878da4df929b30407363ac6c270eaddef1dc24 | production--2018-09-20--21-04-14, staging--2018-09-18--21-28-00, e1feb501b9bee5043f7775f07f8bfbdef360efb0
2018-09-18 22:26:57+02:00 | a788696ee75511a972fb517bc2b2628d40131dc3356f89e102b611a5123d6d12 | staging--2018-09-18--20-27-19, 3b746cbbceef5cb145f5138baa9e32f7312432ef
2018-09-17 16:49:32+02:00 | 635a81eacff571bbee6b7247ae47914e5167efbefad6e817456a50d7d41bef15 | production--2018-09-17--21-35-39, staging--2018-09-17--14-53-12, 03aa9d2c4343c6ed07292f68700cecfa46167162, production--2018-09-20--21-05-27

It’s very hard to understand what image to use if I want to ‘just’ roll-back.

  • Is it the one before the latest?
  • Is it the last one that has production in the name?
  • I’m also seeing images with staging in the name, what does that mean for all other images?
  • What does the comma-separated list mean inside the tags column?
  • What is the digest? It definitely can’t be passed to hokusai production deploy

These are not the types of questions one should have to ask when dealing with a situation that warrants a roll-back.

In the end, what I had to do was find the last one that has a production--dddd-dd-dd--dd-dd-dd tag, and run hokusai production deploy production--2018-09-25--10-19-20.


I suggest the following changes:

  • Add ability to filter the list by production, staging, all, but maybe default to production.
  • Remove the digest column (at least by default, if it’s actually useful for anything, and move it after the tag column)
  • Introduce a hokusai pipeline rollback production convenience command that simply does a deploy to the previously deployed tag, because everybody should be able to understand that and provide a sense of safety

Implement a debug command / commands

Currently hokusai [staging|production] run launches a new container, but implement a way to interact with a running container.

Kubectl provides the exec command to run a command or attach the current session to a running container and port-forward to attach a local port to a remote port

Proposal:

hokusai [staging|production] debug to call kubectl exec -t -i {pod} -- {command} and attach a session to the current shell for a given pod or select the first pod matching the application's selectors from all available running pods - accept an option to override the shell command, otherwise /bin/sh

hokusai [staging|production] attach to call kubectl port-forward {pod} {port}:{port} for a given pod or select the first pod matching the application's selectors from all available running pods - accept an option to specify the port to forward to/from localhost, otherwise 80

Support docker-compose version 1.23.0

Docker-compose version 1.23.0 introduces a randomly-generated hex string appended to all container names, which breaks hokusai test as it calls docker wait {name of the container} where it assumes the name of the test container to be hokusai_{project_name}_1

dev command is counter-intuitive

Running hokusai dev start should foreground by default - only background when -d / --detach is provided

Also update help / docs on subcommand actions

Push git tags back upstream on deploy / promote

It would be nice to see the Hokusai tagging structure created for deploys / promotes {staging/production}--%yyyy-%mm-%dd--%hh-%MM-%ss pushed back to the upstream repo on deploy... though this would require CI to have a deploy key with write access.

Implement as a flag --push-git-tags {remote} that can be added to deploy / promote commands

Should RAILS_ENV be production in staging?

There's no official staging environment supported in Rails. Starting a project with RAILS_ENV=staging would require creating a new config/environments/staging.rb file (presumably similar to production.rb) and potentially impact gems (that might test for Rails.env.production? or even bundler (that might not load gems from the :production group).

It's recommended instead that staging apps use RAILS_ENV=production, with any different behaviors controlled by environment variables (see below links). I suggest that hokusai generate its staging.yml template with RAILS_ENV=production.

https://devcenter.heroku.com/articles/deploying-to-a-custom-rails-environment
https://devcenter.heroku.com/articles/multiple-environments

Hokusai pipeline gitdiff / gitlog do not always resolve git-SHA1 tags correctly

Ran into the situation when running hokusai pipeline [gitdiff/gitlog] that Hokusai did not correctly resolve the staging and production tags to git-SHA1 tags:

$ hokusai pipeline gitlog -v
==> hokusai exec `kubectl --context staging get deployment --selector app=waves,layer=application -o json`
==> hokusai exec `kubectl --context production get deployment --selector app=waves,layer=application -o json`
Comparing staging to 91dcb5fcf4f58984636a0d85d3573f0e66cb27e5
==> hokusai exec `git log --right-only staging..91dcb5fcf4f58984636a0d85d3573f0e66cb27e5`
fatal: ambiguous argument 'staging..91dcb5fcf4f58984636a0d85d3573f0e66cb27e5': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Traceback (most recent call last):
  File "/Library/Python/2.7/site-packages/hokusai/lib/command.py", line 12, in wrapper
    result = func(*args, **kwargs)
  File "/Library/Python/2.7/site-packages/hokusai/commands/gitlog.py", line 31, in gitlog
    shout("git log --right-only %s..%s" % (production_tag, staging_tag), print_output=True)
  File "/Library/Python/2.7/site-packages/hokusai/lib/common.py", line 55, in shout
    return check_call(verbose(command), stderr=STDOUT, shell=True)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 540, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command 'git log --right-only staging..91dcb5fcf4f58984636a0d85d3573f0e66cb27e5' returned non-zero exit status 128

The output of hokusai registry images was, in this moment:

$ hokusai registry images

Image Pushed At           | Image Digest                                                     | Image Tags
-------------------------------------------------------------------------------------------------------------------------------
2018-02-22 23:31:20+01:00 | 3d4e72c8c587fc186a6727862e57463273f6a0d600bedfbb7685e34aa67aefb9 | staging, staging--2018-02-22--22-31-35, latest, 91dcb5fcf4f58984636a0d85d3573f0e66cb27e5
2018-02-21 20:23:49+01:00 | 60487d579f3263fa314273f4334719e374ed04982a50eeb7dde396088e3b0523 | staging--2018-02-21--19-29-19, f0fc132bb4845e784dfd8b59ec4913473a70060d
2018-02-21 20:20:19+01:00 | a99eb51d854ab8617d7615a967779e6886c7a0d9d325d7fb17a07daac3917a52 | bc22372c6f09587b6467ae8ab29dc3d9eefec1ec, staging--2018-02-21--19-27-47
2018-02-19 15:44:44+01:00 | c90af0ae16184575accbf6dacd1b585b354b981fad89bdebc68383116976a34d | staging--2018-02-19--14-45-00, e46b577c70c4fc802020231fab8168e5918ee33a
2018-02-19 15:24:58+01:00 | 3b0a53b5939603defaf4be1b85a2fa4a4a43c333897da127dc86ffb6415ecdab | 0d88e0ce6430acfe5554fb40c0b963f715f76fed, staging--2018-02-19--14-25-15
2018-02-16 23:06:39+01:00 | abedd9bea0ab11751fee6c2ef3ec54020c3a6f77a118f51247b8a4fac9458ffb | staging--2018-02-16--22-07-12, 9fbf5db32456d376f1e3c3db629ff8c7c7db5dff
2018-02-15 19:34:49+01:00 | 6a26dd19d1044704491f4b3995c7768a8c4379e54895bdbe0eaf19ac14226532 | staging--2018-02-15--18-35-09, 91c0fb57405040d20be438a98bb809e1f0bf1a7a
2018-02-13 18:45:13+01:00 | 41a41e2c3a60a41abcfb99488e7e499e1931eba9b0faecb7993679755b49270e | production, production--2018-02-15--17-47-31, staging--2018-02-13--17-45-32, 29c52eea8becf897bf6e3a1908f3de6809dc0563
2018-02-13 18:25:37+01:00 | da14309f7695ece3c7ea293016b59cd89b26c4c12cb6de7a00a13e52cc42e92c | staging--2018-02-13--17-25-55, eb2977f867381455e0fef4d6ab2508cebff04394
2018-02-09 19:54:38+01:00 | 726be8795f2d482a04dcc2143ffd64d2b975f0d5cf87b796c2ac81d16dd7dad9 | 6b8a71bf4eb1e6bc456237668fe15739440c8357, staging--2018-02-09--18-54-56
2018-02-09 18:43:46+01:00 | 50de06a048ab78a0d545f619ea8a1469f553944ac5ef7a4b1956f88542345d0a | d471dbd041c58314fa6f268502507081affab6d0

Hokusai test removes development containers

The command hokusai test cleans up containers after it is done. As it is set up now, this ends up being the same as the development containers, so running hokusai test blows away any work done in hokusai dev run {db setup command} or hokusai dev * stack, in the case of databases...

Either:

  • Template development and test environments as separately named stacks so they don't override
  • Do not clean up test containers by default when test suite exits

Dockerfile and ENV updates to serve assets

I ran into a few hiccups when setting up a Rails project for the first time.

(1) To ensure that fingerprinted asset files are generated and available for serving from within the container, I had to add this to the Dockerfile after the WORKDIR command:

RUN bundle exec rake assets:precompile

Note that this slows down dev/test commands significantly, and isn't strictly required in those contexts. Maybe there's a better formulation for this?

(2) I also had to add this ENV var indicating that Rails should serve static files (since it's often behind an Nginx/Apache web server that serves static files directly, this isn't the default):

hokusai env set RAILS_SERVE_STATIC_FILES=true --staging

To be honest, I'm not sure where suggested ENV values should go in the hokusai workflow, since there's no "default" configMap. Maybe they should go into the staging.yml and production.yml templates, or at least be documented?

Option to enable tty by default?

I realized today that I've never not wanted to run --tty when running a command on our cluster. What do you think about an environment variable I can set so I don't have to include it each time? Let me know and I can send a PR 👍

Encoding error saving env var

Running hokusai production env set SALT=$2a$10$IYNpT4qagy5G3a there appears to be an encoding problem as hokusai production env get SALT then returns SALT=a0

Can't set this via the k8s dashboard - it defaults to ""

Can set it via kubectl edit configmap

Setup CI builds

  • Setup test runner on CircleCI
  • Run Pyinstaller builds for darwin / linux and publish pre-releases on merges to master
  • Flow for creating Github releases synced to pip releases and Docker image builds

Pushing local conf via `[staging|production] update` can be hazardous

Currently, hokusai [staging|production] update pushes config from your local checkout. As part of a build-and-deploy workflow, it is not guaranteed that anyone running this command will have their local repo in-sync with the latest HEAD on a given branch.

Proposed solution:

  • git check that current branch is up-to-date with: git fetch --all --prune && git diff <branch> <origin/branch>
  • store the config somewhere else, matched to each commit and run an update as part of a deploy (this would require refactoring the workflow)

Org-wide config

Load an org-wide config file from a https URI / S3 bucket to provide:

  • Required Hokusai version
  • Required Kubectl version
  • Kubectl configuration

To avoid unnecessary network overhead, an md5 hash of the file could also be expected at a given URI and checked against a locally-cached copy.

A timestamp could be written to a local cache so as to only check this hash / fetch the file after a configured interval.

Related: #86

Configure Rails stacks to log to STDOUT

When setting up a Rails stack for the first time, I was puzzled that requests weren't appearing in the Kubernetes logs. It turns out I had to enable logging to STDOUT via:

hokusai env set RAILS_LOG_TO_STDOUT=true --staging

Much like #20, I'm not sure if this should go into the default .yml files generated for Rails projects or just be documented.

And the ENV var is only respected starting in Rails 5. Earlier projects will need the rails_12factor gem.

`hokusai check` fails due to unset kubectl context

I installed and configured hokusai according to our internal Artsy docs.

Running hokusai check unexpectedly fails on kubectl not found, though kubectl is installed correctly. Hokusai appears to work correctly even though the check fails. The issue appears to be that the check runs kubectl version, which returns a non-zero exit code as kubectl config current-context is unset.

The exact output I get from running kubectl version:

Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.3", GitCommit:"0480917b552be33e2dba47386e51decb1a211df6", GitTreeState:"clean", BuildDate:"2017-05-10T15:48:59Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"}
Unable to connect to the server: dial tcp: lookup localhost on 8.8.8.8:53: no such host

Fail with informative error message when trying to diff with outdated checkout

Instead of:

$ hokusai pipeline gitlog
Comparing 2b88e376a9d007df8234b1cd8c17a1838d673d32 to 72a9c0bc4c854cd8e47043651ecbefd56e901f21
fatal: Invalid revision range 2b88e376a9d007df8234b1cd8c17a1838d673d32..72a9c0bc4c854cd8e47043651ecbefd56e901f21
ERROR: Command 'git log --right-only 2b88e376a9d007df8234b1cd8c17a1838d673d32..72a9c0bc4c854cd8e47043651ecbefd56e901f21' returned non-zero exit status 128

The tool should tell the user to fetch all latest objects from the remote.

Be able to deploy specific PRs (Canary apps?)

Feature request

Currently one of the things we lose when switching from Heroku to K8s is the ability to create test/sample apps on PR level. Heroku offers sample apps which allows us to bring up a new stack of the app for specific PR and define which config values to copy from staging.

List review apps

Unless I'm missing something, I don't think there's a way to see a list of the review apps for a project. This would be a nice way to ensure we're using the right name for an app and that we've cleaned up after ourselves.

setup fails with ECR permission errors

When I run

hokusai setup --aws-account-id <redacted> 2 --project-type elixir

I get an error message:

ERROR: An error occurred (AccessDeniedException) when calling the DescribeRepositories operation: User: arn:aws:iam::<redacted>:user/barry is not authorized to perform: ecr:DescribeRepositories on resource: *

However, I can run this command successfully:

aws ecr describe-repositories

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.