Merge pull request #15 from stelligent/develop

Release version 0.1.0

.gitignore

@@ -1,2 +1,3 @@
 *.iml
 .idea
+release/

.travis.yml

@@ -0,0 +1,36 @@
+language: go
+
+go:
+  - 1.7.x
+
+os:
+  - linux
+
+## Encrypted GITHUB_TOKEN
+env:
+  secure: Y2fHWCGvx3ngUdx2siNT55cQ6rJGjtwIQIvrfjtetaXUQw0D3WHc+7hU52horb7kutD1C2BG4OBPxMOl0PtS2+3fy0p2LSI6hy1UPoVs00YWkTIqlNzfdLv9ATi+xdF8VqpjgHB+bQRMohiBKdfN/oWcrszLdukAWwL4EsMinlRKol+RODduQruG9jXWBoQIyoiutargapyEaTLDxRcCsUome9LKlzwd+mQlpO1maQrvop/QYBinglkehJ1DSLtgzl7tdHm4tEix/4+7eGX8NL4dMiA6xxKQg4JT2kbRr5Tb35QEPonA9D1DJ9JPkX+KRiatGGw2FMBofMPBB/NkliRMg6nkqn2yPshXfvnin/RhyMbrlBLNRoeO0z3puyPdmy3whQMNqhnd0QC0y53t/MGNhhoPxJVrctljz9AyZ0WRGSdXW0oCGa91gnKUKobZs8foQA6LQXTCJzLUl5WP8iiWcXX8kWE8+XcO0NuD1Bo6i30HUTLk+H91b/pSK8ewvHfaXqsjNaMFdFvuFjfEGnm8O9II+Dvr2equo3TvhEY+TQ1EeUVeXR8tp33rSKhBeoaMNpTghmNueI0PzUyG/giqTVM81nysHTfe8lQE1bfTphu2mth4Zuq86jsPNorII2yAtlP6qvbV6uAGPvYJ5XYHG7OBeRIaeqRS480hbNg=
+
+
+## Don't buid when new release tags are pushed
+branches:
+  except:
+    - /^v[0-9]/
+
+## Setup GitHub credentials so we can push tags
+before_deploy:
+  - git config credential.helper "store --file=.git/credentials"
+  - echo "https://${GITHUB_TOKEN}:@github.com" > .git/credentials
+
+deploy:
+  ## Create 'pre-release' from 'develop' branch
+  - provider: script
+    skip_cleanup: true
+    script: make dev-release
+    on:
+      branch: develop
+  ## Create 'release' from 'master' branch
+  - provider: script
+    skip_cleanup: true
+    script: make release
+    on:
+      branch: master

DESIGN.md

@@ -0,0 +1,115 @@
+# Problem Statement
+Amazon ECS (EC2 Container Service) provides an excellent platform for deploying microservices as containers.  The challenge however is that there is a significant learning curve for microservice developers to deploy their applications in an efficient manner.  Specifically, they must learn to use CloudFormation to orchestrate the management of ECS, ECR, EC2, ELB, VPC, and IAM resources.  Additionally, tools like CodeBuild and CodePipeline must be mastered to create a continuous delivery pipeline for their microservices.
+
+To address these challenges, we will create a tool to simplify the declaration and administration of the AWS resources necessary to support microservices.  Similar to how the [Serverless Framework](https://serverless.com/) improved the developer experience of Lambda and API Gateway, this tool will make it easier for developers to use ECS as a microservices platform.
+
+For more details on the intended architecture, see [Microservices Platform with ECS](https://stelligent.com/2016/10/06/microservices-platform-with-ecs/).
+
+#Assumptions
+1. **Polyglot** - There will be no prescribed language or framework for developing the microservices.  The only requirement will be that the service will be run inside a container and exposed via an HTTP endpoint.
+2. **Cloud Provider** - At this point, the tool will assume AWS for the cloud provider and will not be written in a cloud agnostic manner.  However, this does not preclude refactoring to add support for other providers at a later time.
+3. **Declarative** - All resource administration will be handled in a declarative vs. imperative manner.  A file will be used to declared the desired state of the resources and the tool will simply assert the actual state matches the desired state.  The tool will accomplish this by generating CloudFormation templates.
+4. **Stateless** - The tool will not maintain its own state.  Rather, it will rely on the CloudFormation stacks to determine the state of the platform.
+5. **Secure** - All security will be managed by AWS IAM credentials.  No additional authentication or authorization mechanisms will be introduced.
+6. **Language** - TBD.  Need to determine the language to use for developing the tool.  Options in order of preference include Go, Node.js, Python.
+
+
+#Capabilities
+## Resource Declaration
+A YAML file will be used to declare microservice resources.  There are two types of resources defined in the YAML file, environments and services.
+
+Environments contain an ECS cluster, ECS container instances (with ASG), and an ALB.  Additionally, environments contain (or reference) a VPC.  A sample environment resource may look like:
+
+
+```
+-
+environments:
+  dev:
+    loadbalancer:
+      hostname: api-dev.example.com
+    cluster:
+      desiredCapacity: 1
+      maxSize: 1
+  production:
+    loadbalancer:
+      hostname: api.example.com
+    cluster:
+      desiredCapacity: 2
+      maxSize: 5
+```
+
+
+Services contain an ECS service, ECS task, ALB target group and ECR.  Additionally service can contain an optional CodeBuild and CodePipeline resource for a CD pipeline.
+```
+-
+service:
+  desiredCount: 2
+  pipeline:
+    devEnvironment: dev
+    prodEnvironment: production
+```
+
+## CLI
+The majority of code for this tool will be to provide a CLI to manage CloudFormation stacks based on the resources declared in the YAML file.  The list of available commands are:
+
+```
+# List all environments
+> mu env list
+
+# Show details about a specific environment (ECS container instances, Running services, etc)
+> mu env show <environment_name>
+
+# Upsert an environment
+> mu env up <environment_name>
+
+# Terminate an environment
+> mu env terminate <environment_name>
+
+# Show details about a specific service (Which versions in which environments, pipeline status)
+> mu service show [-s <service_name>]
+
+# Deploy the service to an environment
+> mu service deploy <environment_name> [-s <service_name>]
+
+# Set an environment variable(s) for a service
+> mu service setenv <environment_name> [-s <service_name>] key=value[,...]
+
+# Undeploy the service from an environment
+> mu service undeploy <environment_name> [-s <service_name>]
+
+# List the pipelines
+> mu pipeline list
+
+# Show the pipeline details for a specific service
+> mu pipeline show <service_name>
+
+# Upsert the pipeline
+> mu pipeline up [-s <service_name>] [-u <repo_url>] [-t <repo_token>]
+
+# Terminate the pipeline
+> mu pipeline terminate [-s <service_name>]
+```
+
+
+## Plugin
+A plugin framework should be available for developer to contribute extensions for specific languages.  For example, a Java developer using Spring Boot should be able to use a Spring Boot plugin to define the Eureka, ConfigServer and Zuul router for their environment as follows:
+
+```
+environments:
+  dev:
+    loadbalancer:
+      hostname: api-dev.example.com
+    springboot:
+      eureka:
+        desiredCapacity: 1
+      configServer:
+        sourceUrl: https://github.com/example/configrepo
+```
+
+      
+## UI
+A web based user interface will be created to provide visibility into the resources in the platform.   The UI will allow a view into the list of pipelines, services, and environments defined in a given AWS account.  It will only provide read only access to the resources and will not provide ability to change the resources.
+
+The UI will consist of an Angular2 application hosted in S3 with APIs in Lambda/API Gateway.  The UI will be secured via AWS credentials and Cognito. 
+
+

LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2016 Stelligent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

Makefile

@@ -0,0 +1,69 @@
+ORG := stelligent
+PACKAGE := mu
+TARGET_OS := linux windows darwin
+
+###
+BRANCH := $(or $(TRAVIS_BRANCH), $(shell git rev-parse --abbrev-ref HEAD))
+IS_MASTER := $(filter master, $(BRANCH))
+VERSION := $(shell cat VERSION)$(if $(IS_MASTER),,-$(BRANCH))
+ARCH := $(shell go env GOARCH)
+BUILD_FILES = $(foreach os, $(TARGET_OS), release/$(PACKAGE)-$(os)-$(ARCH))
+UPLOAD_FILES = $(foreach os, $(TARGET_OS), $(PACKAGE)-$(os)-$(ARCH))
+GOLDFLAGS = "-X main.version=$(VERSION)"
+TAG_VERSION = v$(VERSION)
+
+default: build
+
+setup:
+	@echo "=== preparing $(VERSION) from $(BRANCH) ==="
+	mkdir -p release
+	go get -u "github.com/golang/lint/golint"
+	go get -u "github.com/aktau/github-release"
+	go get -t -d -v ./...
+
+lint: setup
+	@echo "=== linting ==="
+	go vet ./...
+	golint ./...
+
+test: lint
+	@echo "=== testing ==="
+	go test ./...
+
+build: test $(BUILD_FILES)
+
+$(BUILD_FILES): setup
+	@echo "=== building $(VERSION) - $@ ==="
+	GOOS=$(word 2,$(subst -, ,$@)) GOARCH=$(word 3,$(subst -, ,$@)) go build -ldflags=$(GOLDFLAGS) -o '$@'
+
+release-clean:
+ifeq ($(IS_MASTER),)
+	@echo "=== clearing old release $(VERSION) ==="
+	github-release info -u $(ORG) -r $(PACKAGE) -t $(TAG_VERSION) && github-release delete -u $(ORG) -r $(PACKAGE) -t $(TAG_VERSION) || echo "No release to cleanup"
+	git push --delete origin $(TAG_VERSION) || echo "No tag to delete"
+endif
+
+release-create: release-clean
+	@echo "=== creating pre-release $(VERSION) ==="
+	git tag -f $(TAG_VERSION)
+	git push origin $(TAG_VERSION)
+	echo "waiting for dust to settle..." && sleep 5
+	github-release release -u $(ORG) -r $(PACKAGE) -t $(TAG_VERSION) -p
+
+$(TARGET_OS): release-create
+	@echo "=== uploading $@ ==="
+	github-release upload -u $(ORG) -r $(PACKAGE) -t $(TAG_VERSION) -n "$(PACKAGE)-$@-$(ARCH)" -f "release/$(PACKAGE)-$@-$(ARCH)"
+
+dev-release: $(TARGET_OS)
+
+release: dev-release
+ifneq ($(IS_MASTER),)
+	@echo "=== releasing $(VERSION) ==="
+	github-release edit -u $(ORG) -r $(PACKAGE) -t $(TAG_VERSION)
+endif
+
+clean:
+	@echo "=== cleaning ==="
+	rm -rf release
+
+.PHONY: default lint test build setup clean release-clean release-create dev-release release $(UPLOAD_FILES) $(TARGET_OS)

README.md

@@ -1,56 +1,23 @@
-# Problem Statement
+[![Build Status](https://travis-ci.org/stelligent/mu.svg?branch=develop)](https://travis-ci.org/stelligent/mu)
+
+# Why?
 Amazon ECS (EC2 Container Service) provides an excellent platform for deploying microservices as containers.  The challenge however is that there is a significant learning curve for microservice developers to deploy their applications in an efficient manner.  Specifically, they must learn to use CloudFormation to orchestrate the management of ECS, ECR, EC2, ELB, VPC, and IAM resources.  Additionally, tools like CodeBuild and CodePipeline must be mastered to create a continuous delivery pipeline for their microservices.
 
-To address these challenges, we will create a tool to simplify the declaration and administration of the AWS resources necessary to support microservices.  Similar to how the [Serverless Framework](https://serverless.com/) improved the developer experience of Lambda and API Gateway, this tool will make it easier for developers to use ECS as a microservices platform.
+To address these challenges, this tool was created to simplify the declaration and administration of the AWS resources necessary to support microservices.  Similar to how the [Serverless Framework](https://serverless.com/) improved the developer experience of Lambda and API Gateway, this tool makes it easier for developers to use ECS as a microservices platform.
 
 For more details on the intended architecture, see [Microservices Platform with ECS](https://stelligent.com/2016/10/06/microservices-platform-with-ecs/).
 
-#Assumptions
-1. **Polyglot** - There will be no prescribed language or framework for developing the microservices.  The only requirement will be that the service will be run inside a container and exposed via an HTTP endpoint.
-2. **Cloud Provider** - At this point, the tool will assume AWS for the cloud provider and will not be written in a cloud agnostic manner.  However, this does not preclude refactoring to add support for other providers at a later time.
-3. **Declarative** - All resource administration will be handled in a declarative vs. imperative manner.  A file will be used to declared the desired state of the resources and the tool will simply assert the actual state matches the desired state.  The tool will accomplish this by generating CloudFormation templates.
-4. **Stateless** - The tool will not maintain its own state.  Rather, it will rely on the CloudFormation stacks to determine the state of the platform.
-5. **Secure** - All security will be managed by AWS IAM credentials.  No additional authentication or authorization mechanisms will be introduced.
-6. **Language** - TBD.  Need to determine the language to use for developing the tool.  Options in order of preference include Go, Node.js, Python.
-
-
-#Capabilities
-## Resource Declaration
-A YAML file will be used to declare microservice resources.  There are two types of resources defined in the YAML file, environments and services.
-
-Environments contain an ECS cluster, ECS container instances (with ASG), and an ALB.  Additionally, environments contain (or reference) a VPC.  A sample environment resource may look like:
+# Installation
 
+```bash
+# Install latest version to /usr/local/bin
+curl -s https://raw.githubusercontent.com/stelligent/mu/master/install.sh | sh
 
-```
--
-environments:
-  dev:
-    loadbalancer:
-      hostname: api-dev.example.com
-    cluster:
-      desiredCapacity: 1
-      maxSize: 1
-  production:
-    loadbalancer:
-      hostname: api.example.com
-    cluster:
-      desiredCapacity: 2
-      maxSize: 5
+# Install v0.1.0 version to ~/bin
+curl -s https://raw.githubusercontent.com/stelligent/mu/master/install.sh | INSTALL_VERSION=0.1.0 INSTALL_PATH=~/bin sh
 ```
 
-
-Services contain an ECS service, ECS task, ALB target group and ECR.  Additionally service can contain an optional CodeBuild and CodePipeline resource for a CD pipeline.
-```
--
-service:
-  desiredCount: 2
-  pipeline:
-    devEnvironment: dev
-    prodEnvironment: production
-```
-
-## CLI
-The majority of code for this tool will be to provide a CLI to manage CloudFormation stacks based on the resources declared in the YAML file.  The list of available commands are:
+## Commands
 
 ```
 # List all environments
@@ -91,25 +58,4 @@ The majority of code for this tool will be to provide a CLI to manage CloudForma
 ```
 
 
-## Plugin
-A plugin framework should be available for developer to contribute extensions for specific languages.  For example, a Java developer using Spring Boot should be able to use a Spring Boot plugin to define the Eureka, ConfigServer and Zuul router for their environment as follows:
-
-```
-environments:
-  dev:
-    loadbalancer:
-      hostname: api-dev.example.com
-    springboot:
-      eureka:
-        desiredCapacity: 1
-      configServer:
-        sourceUrl: https://github.com/example/configrepo
-```
-
-      
-## UI
-A web based user interface will be created to provide visibility into the resources in the platform.   The UI will allow a view into the list of pipelines, services, and environments defined in a given AWS account.  It will only provide read only access to the resources and will not provide ability to change the resources.
-
-The UI will consist of an Angular2 application hosted in S3 with APIs in Lambda/API Gateway.  The UI will be secured via AWS credentials and Cognito. 
-
 

VERSION

@@ -0,0 +1 @@
+0.1.0

buildspec.yml

@@ -0,0 +1,11 @@
+version: 0.1
+
+phases:
+  build:
+    commands:
+      - go get -t -d -v ./...
+      - go build -v -o mu main.go
+      - ls
+artifacts:
+  files:
+    - mu

environments/list.go

@@ -4,6 +4,7 @@ import(
 	"fmt"
 )
 
+// List all environments
 func List() {
 	fmt.Println("listing environments")
 }

environments/show.go

@@ -4,6 +4,7 @@ import(
 	"fmt"
 )
 
+// Show enviroments
 func Show(environment string) {
 	fmt.Printf("showing environment: %s\n",environment)
 }

environments/terminate.go

@@ -4,6 +4,7 @@ import(
 	"fmt"
 )
 
+// Terminate an environment
 func Terminate(environment string) {
 	fmt.Printf("terminating environment: %s\n",environment)
 }

environments/upsert.go

@@ -4,6 +4,7 @@ import(
 	"fmt"
 )
 
+// Upsert an environment
 func Upsert(environment string) {
 	fmt.Printf("upserting environment: %s\n",environment)
 }