Giter VIP home page Giter VIP logo

pavedroad-io / roadctl Goto Github PK

View Code? Open in Web Editor NEW
1.0 4.0 0.0 118.84 MB

A kubectl compatible CLI for managing and creating applications and defining/managing CI/CD environments. The roadctl command uses blueprints based on provent design patterns driven by produciton metrics.

License: Apache License 2.0

Go 97.37% Makefile 2.49% Shell 0.14%
pr-kpi kubernetes golang microservice functions ci-cd skaffold docker

roadctl's Introduction

PavedRoad, Inc.

Build StatusGo Report CardQuality Gate StatusLines of CodeDuplicated Lines (%)Maintainability RatingReliability RatingTechnical DebtSecurity RatingVulnerabilitiesFOSSA Status

Roadctl

Roadctl is a command line interface for:

  • Creating microservices, CRDs, and serverless functions from low-code blueprints
  • Managing a preconfigured CI/CD pipeline
  • Controlling deployment options

This overview covers roadctl syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the roadctl reference documentation. For installation instructions see installing roadctl.

Syntax

Use the following syntax to run roadctl commands from your terminal window:

$ roadctl [command] [TYPE] [NAME] [flags]

Where command, TYPE, NAME, and flags are:

  • command: Specifies the operation that you want to perform on one or more resources, for example create, get, describe, delete
  • TYPE: Specifies the resource type. Resource types are case insensitive and you can specify the singular, or plural forms. For example, the following commands produce the same output:
    $ roadctl get blueprint blueprint1
    $ roadctl get blueprints blueprint1
  • NAME: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example roadctl get blueprints
  • flags: Specify roadctl global options or command specific options

Resource Types

The following table includes a list of all the supported resource types:

Resource Type Description
builders Manage build pipelines to produce compiled results such as code and CSS
environments Manages target environments to deploy into, for example dev, test, staging
packagers Create images/containers along with manifest for docker, docker-compose, and Kubernetes
taggers Support tagging artifacts, images, and releases
tests Manage unit, function, benchmarks, and container tests
blueprints Allow applications to be built from predefined blueprints such as API gateways or data managers
integrations Allows you to tailor the preconfigured integrations
artifacts Manage development artifacts such as logs and code coverage
providers Manage local and cloud providers you want to deploy to
deployments Manage deployment strategies for various environments

Output Options

By default, roadctl outputs the results of a command as text. However, you can control that by using the --format option:

--format text
--format json
--format yaml

Requirements Before You Begin

FOSSA Requirements

Support for FOSSA is integrated in the generated Makefile. Please set up your FOSSA account and add the following variable to your environment before executing make:

$ export FOSSA_API_KEY="XXXXXXXXXXXXXXXXXXXXXXXXXX"

NOTE: You can disable FOSSA in the integrations section of your definitions file you don't need it.

SonarCloud Requirements

PavedRoad utilizes SonarCloud to champion quality code in this project. Please set up your SonarCloud account and the following environment variable to take full advantage of the CLI:

$ export SONARCLOUD_TOKEN="#########"

NOTE: You can disable SonarCloud in the integrations section of your definitions file you don't need it.

Examples: Common Operations

Initialize a Local Template Repository

The following command populates available blueprints on your local hard drive. By default, they are placed $HOME/.pavedroad.d/blueprints.

$ roadctl init

Print a List of Available Templates

The roadctl command can print all available blueprints or verify an individual blueprints name. The output includes the blueprints type, name and its release status.

$ roadctl get blueprints

Or

$ roadctl get blueprints name

Example output for the above command with no name specified:

Template Type   Name                 Release Status
crd             kubebuilder          incubation
microservices   workerPool           ga
microservices   ux                   ga
microservices   service              ga
microservices   datamgr              ga
microservices   gateway              ga
microservices   subscriber           experimental
serverless      go-knative           ga
serverless      go-open-faas         ga

The meaning for each type of release status is as follows:

Release Status Meaning
ga For general availability
incubation For blueprints working towards ga
experimental Not stable or work in progress or simple examples

Create and Edit a Template Definitions File

The blueprints definitions file allow you to tailor your application to your requirements, such as:

  • Define fields and structures to create
  • Specify community files
  • Tailor the initial integrations that get included
  • Set organizational and project information like: license, company name, or project description

Each blueprints comes with a default definitions file you can use as a beginning point.

Use the describe command to create your definitions file:

$ roadctl describe blueprints datamgr > myNewService.yaml

Partial example output:

tables:
- columns:
  - constraints: ""
    mapped-name: id
    modifiers: ""
    name: id
    type: string
  - constraints: ""
    mapped-name: title
    modifiers: ""
    name: title
    type: string
  - constraints: ""
    mapped-name: updated
    modifiers: ""
    name: updated
    type: time
  - constraints: ""
    mapped-name: created
    modifiers: ""
    name: created
    type: time
  parent-tables: ""
  table-name: users
  table-type: jsonb
- columns:
  - constraints: ""
    mapped-name: id
    modifiers: ""
    name: id
    type: string
  parent-tables: users
  table-name: metadata
- columns:
  - constraints: ""
    mapped-name: key
    modifiers: ""
    name: key
    type: string
  parent-tables: metadata
  table-name: test

Then edit it using vi:

$ vi myNewService.yaml

To See Valid Contents of a Template

Use the explain command to learn the valid syntax for the named blueprints is:

$ roadctl explain blueprints datamgr

Partial example output:

Name: blueprints

DESCRIPTION:
Templates provide a low-code environment for serverless, CRD, and microservices.
The roadctl CLI uses the blueprints skaffold combined code generation to create your
application, CI, and test framework.

FIELDS:
name <string>
     A user friendly name for this blueprints
api-version <string>
     API version used to generate it
version <string>
     Object data model version
id <string>
     UUID that uniquely identified a combination of api-verion + version
     This UUID is immutable for the above combination

Generate an Application

Will build your source code, test cases, integrations, documentation, and CI pipeline

$ roadctl create blueprints datamgr -f myNewService.yaml

To compile and invoke the CI/CD pipeline enter:

$ make

Build Defaults

The defaults are to execute lint, go sec, go vet, go test, and the FOSSA and SonarCloud scanners.

  • The artifacts hold the results for each command

The build generates the following components:

  • Go source code
  • Dependency graph
  • Swagger API specification in docs/api.json
  • HTML service documentation in docs/myServiceName.html
  • HTML API documentation in docs/api.html
  • Dependency management with dep and insure all includes are present
  • Dockerfile
  • docker-compose files
  • Kubernetes manifests
  • Skaffold configuration file
  • Go test harness

The deployment options are:

  • Push image to local microk8s instance
  • Push service and run service to local microk8s instance

Make Options

Make can be executed with the following options:

Make Options Meaning
$ make Check and compile the code
$ make compile Just compile the code
$ make check Just execute the test suite
$ make deploy Package and deploy code to local k8s cluster
$ make fmt Rewrite code in go formatting
$ make simplify Format and simplify the code use

Initializing the Template Repository

A GitHub repository stores the PavedRoad blueprints.

As of version 0.6, the git clone command is the default method for creating blueprints repositories. The default is to checkout the "release" branch:

$ roadctl init

To use a different branch, use the --branch option:

$ roadctl init --branch <branch-name>

Templates Location

The default location for the blueprints is $HOME/.pavedroad.d/blueprints.

This can be changed by setting the PR_TEMPLATE_DIR environment variable, or via the roadctl command line with the _--blueprints flag.

GitHub Authentication

For backward compatibility, use the --api option with authentication.

The GitHub API enforces rate limits that may affect your ability to download blueprints. Authenticated users have significantly higher rate limits. You can provide GitHub authentication using HTTP basic authentication or an OAUTH2 access token.

From the Command Line

$ roadctl init --api --password XXXXXXX --user YYYYYYY

Or

$ roadctl init --token #######

Using Environment Variables

$ export GH_ACCESS_TOKEN="#########"

Or

$ export GH_USER_NAME="#########"
$ export GH_USER_PASSWORD="#########"

Or a Combination

$ roadctl init --api --user YYYYYYY
$ export GH_USER_PASSWORD="#########"

Package and deploy code to local k8s cluster:

$ make deploy

Rewrite code in go formatting:

$ make fmt

Or to format and simplify the code use:

$ make simplify

Project Status

The project is an early preview. We realize that it's going to take a village to arrive at the vision of a multi-cloud control plane, and we wanted to open this up early to get your help and feedback. Please see the Roadmap for details on what we are planning for future releases.

Official Releases

Official releases of PavedRoad can be found here: Official Releases.

Please note that it is strongly recommended that you use the official releases of PavedRoad, as unreleased versions from the master branch are subject to changes and incompatibilities that will not be supported in the official releases. Builds from the master branch can have functionality changed and even removed at any time without compatibility support and without prior notice.

Links to More Information

Community Meeting

This project meets on a regular basis: TBD Community Meeting.

Getting Help

For contact information or to report a bug see Support.

How to Contribute

For guidelines on contributions see Contributing.

Code of Conduct

This project follows this Code of Conduct.

License

This project is licensed under the following License.

roadctl's People

Contributors

jscharber avatar markgreenpr avatar shgayle avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar

roadctl's Issues

Tagbar video

Cover vim shortcut integration for tagbar plugin.

Allow explain command to be template specific

Today, the roadctl explain commands reads a text file that documents the datamgr definitions file format. As we add new template types, the documentation needs to be specific to the given template.

This change affects two repositories:

pavedroadio/templates
pavedroadio/roadctl

In the templates repo we want to move

docs/templates.txt to microservices/ga/datamgr/docs/datamanger.txt

Then in roadctl, change it to read from .templates/ga/datamgr/docs/datamager.txt

The change needs is the cmd/templates.go file

// tplExplain
// is stored in docs/explain.txt
// docs is defined by eTLD
// explain is tplResourceName
func tplExplain(tplListOption string, rn string) tplExplainResponse {
var response tplExplainResponse

// Load explaination
fn := defaultTemplateDir + "/" + eTLD + "/" + tplResourceName + ".txt"
if _, err := os.Stat(fn); os.IsNotExist(err) {
return response
}

git gutter video

GitGutter is a vim plugin that provides a visual diff between the current code and the last git commit. It also allows to issue git commands but the preferred method is to use fugitive. We need to explain why and our key mappings

Add Created and Updated fields to generated structs

The code expects date time stamps for each row. Currently, these are inserted in the YAML instead of being generated automatically. If an end-user forgets them, the code breaks when executed.

We want to modify cmd/templates.go to include them automatically

92 // structUUID
93 // name of table, type of data json|yaml
94 const structUUID = "\t%sUUID string %s:%suuid\n"

... const structCreated = ...
const struct Updated = ...

Note, the JSON field string is also not proper

const structUUID = "\t%sUUID string %s:%suuid\n"

should include quotes like this

const structUUID = "\t%sUUID string %s:**"**%suuid**"**\n"

Delve and Skaffold

Needs to cover using Skaffold profiles to create a debug session and attaching using command line dlv to connect to a remote headless instance of dlv.

Use git clone instead of GitHub API to download templates

Currently with checkout templates using the GitHub API. This requires using a PAT to avoid rate limiting. Creating a PAT is a barrier to end-users who want to try roadctl. We need the ability to clone and sync the repository on a publicly accessible server via simple HTTPS.

S3 looks like a possible solution.

Test case for updated and created times fails because of case

The generated test cases for updated and created timestamps fail because we Unmarshall into an interface. This means Created and Updated use the JSON field identifiers which are lowercase.

Switch both to use lowercase.

var m map[string]interface{}
//var md map[string]interface{}
json.Unmarshal(response.Body.Bytes(), &m)

//Test we can decode the data
cs, ok := m["Created"].(string)

Move metrics to core repository

The code for tracking metrics is getting duplicated across micro-services. Create a core library and then use it in templates.

Search for template directory if not found

Issuing template commands when not in the parent directory causes backtraces.

Three changes are required.

  • Search for a template directory
  • Allows template directory to be specified in an environment variable
  • Allows template directory to be specified as a command-line option
  • Return error message if the template directory can't be located

Sample error

$ roadctl describe templates datamgr 
panic: runtime error: slice bounds out of range [:-4]

goroutine 1 [running]:
github.com/pavedroad-io/roadctl/cmd.tplDescribeResponse.RespondWithText(0x0, 0x0, 0x0, 0xc0000953e0, 0xc0000953d0)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/cmd/templates.go:573 +0x2be
github.com/pavedroad-io/roadctl/cmd.runDescribe(0xe7a5a0, 0xc0000a28a0, 0x2, 0x2)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/cmd/describe.go:74 +0x1a2
github.com/pavedroad-io/roadctl/cmd.glob..func8(0xe7a5a0, 0xc0000a28a0, 0x2, 0x2)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/cmd/describe.go:43 +0x49
github.com/spf13/cobra.(*Command).execute(0xe7a5a0, 0xc0000a2820, 0x2, 0x2, 0xe7a5a0, 0xc0000a2820)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/vendor/github.com/spf13/cobra/command.go:830 +0x2aa
github.com/spf13/cobra.(*Command).ExecuteC(0xe79e20, 0xe7ad20, 0xc000113f20, 0x43d03a)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/vendor/github.com/spf13/cobra/command.go:914 +0x2fb
github.com/spf13/cobra.(*Command).Execute(...)
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/vendor/github.com/spf13/cobra/command.go:864
github.com/pavedroad-io/roadctl/cmd.Execute()
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/cmd/root.go:56 +0x31
main.main()
	/home/jscharber/eng/src/github.com/pavedroad-io/roadctl/roadctl.go:35 +0x93

API gateway template

An API gateway is a common design pattern. We need a template that covers this use case.

Frequent shortcuts video

These are two keystroke vim mappings for the most commonly executed commands used in development and testing.

Move badge URLs into integrations.go as constants

Today we put quality badges for MD / HTML into the definitions file making it and end-users problem. We need to move this into the integration logic and generate them. That means the end-user can just specify which badges they want.

If the entire integration is disabled, no badges should be generated and any specified in the definitions file can be ignored.

This is a large change involving

  • Extend github.com/pavedroad-io/integrations to generate all required badges
  • Modify definitions structure to take a list of enabled badges instead of the current enabled, URL, name
  • Modify describe command to use the new syntax
  • Modify existing example code samples
  • Update documentation
  • Update UI structs in github.com/pavedroad-io/frontend

Clean up docs & cheat sheets

Remove docs from .gitignore
Make sure all cheat sheets, and template docs are stored in samples and templates
Remove dangling docs

Ferret video

Ferret provides a multi-file search and replaces via vim. The video needs to demonstrate its usage and explain our key mappings.

Add community files to template generation

Today, we include community files in the YAMLs definitions but we do not create them.

Add them to the template creation process. Only files listed are to be included in templates that are generated.

community:
  community-files:
  - {name: CODE_OF_CONDUCT.md, path: ., src: templatedir}
  - {name: CONTRIBUTING.md, path: ., src: templatedir}
  - {name: COVERNANCE.md, path: ., src: templatedir}
  - {name: MEETING.md, path: ., src: templatedir}
  - {name: OWNERS.md, path: ., src: templatedir}
  - {name: SECURITY.md, path: ., src: templatedir}
  - {md5: '123123123123123123231', name: SUPPORT.md, path: ., src: 'git-api://templates.pavedroad.io/templates/oos/support.md'}
  - {name: ROADMAP.md, path: ., src: 'https://w.pavedroad.io/templates/roadmap.md'}
  - {name: SECURITY.md, path: ., src: templatedir}
  - {name: ROADMAP.md, path: ., src: 'https://w.pavedroad.io/templates/roadmap.md'}
  description: list of community files to include

Modify templates to log to kafka

This will need a design document, at a high level we want:
Implement an event emitter abstraction layer
Create an instance of a kafka emitter
Create a consumer that logs to syslog
Create a consumer that logs to Elastic search
Update logging type with more data, https://docs.microsoft.com/en-us/windows/win32/http/w3c-logging

https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Protocol
https://godoc.org/github.com/Shopify/sarama#example-AsyncProducer--Goroutines
https://godoc.org/github.com/rcrowley/go-metrics#example-GetOrRegisterGauge

[] Need to pick which client to use

Shopify sarama

Large community with no dependencies
MIT license

Confluent, inc

Fast, support automatic partitioning but requires librdkafka
Apache 2 for go lib
librdkafka has restrictions re notifications
License: https://github.com/edenhill/librdkafka/blob/master/LICENSE
godoc

performance benchmarks: https://gist.github.com/savaki/a19dcc1e72cb5d621118fbee1db4e61f

go-vim videos

go-vim integrates go development support into vim. We need a series of videos covering the most commonly used features and our vim key mappings.

add .rcignore to define files not to overwrite

Today, we look for files that contain the work hook, a convention we use for identifying end-user code. However, end-users may also use our sample code like httpJob.go and httpScheduler.

This task will create an equivalent of the .gititnore file that takes regex patterns for files to not modify during template generation.

Ultisnips video and web page

Ultisnips provides support for inserting code and text into projects. This includes pre-defined snippets and user-created snippets. We need a video explaining vim key mappings we've created and pointers to existing tutorials on using Ultisnip. The video needs to cover using fzf to quickly find snippets.

delve debugger video

Delve is the standard debugger for Go and it can be invoked in three different ways.

Command-line
Vim
Or attached to a kubernetes cluster when using Skaffold

We need a video for each of these use cases

Split preflight logic between roadctl and templates

We provide a dev/preflight.sh to help end-users set up their environment. Testing the token environment variables are set correctly and populating the templates directory needs to move inside roadctl as an init method.

Currently, we have

roadctl get templates --init

We move the preflight logic here.

NOTE: GitHub is deprecating support for basic authentication, so start using PAT as the default method.

istio manifest when deploying to k8s

Add an istio manifest for code being deployed to k8s cluster. This can use Skaffold profiles to enable istio support.

This should include HTTPs support

Kafka support

Add docker-compose and kubernetes manifest for supporting docker

The docker version will use, wurstmeister/kafka-docker and zookeeper

This requires setting the environment variable KAFKA_ADVERTISED_HOST_NAME to the IP address of the docker interface.

This work is needed for @MarkGreenPR core log integration.

We can also pre-configure a list of topics for k8s and docker-compose

Add video on setting up DevKit

While setting up a DevKit only takes pasting a curl command, there is nothing showing the user what to expect. Creating a short video to help them understand what will happen.

Allows scheduler and jobs to extend management interface

The work pool template provides a management interface for setting configuration variables and controlling the service. There are two data structures that define commands and fields.

The managementOptions structure contains mgtCommand and Fields. The latter being a list of strings. The managementInit() method initializes the managementOptions in the dispatcher configuration. Management commands are executed by the ProcessManagementRequest() methods.

Several changes need to happen for this work.

The templateScheduler.go and templateJob.go need to add interfaces for:

[ ] Adding commands
[ ] Adding fields
[ ] Processing fields
[ ] The httpScheduler.go and httpJob need to implement those methods

The templateDispatcher.go needs

[ ] Extend management, mgtCommand structure, with an invocation type: internal, scheduler, job
[ ] Call the commands and fields interfaces during initialization adding responses to managementOptions
[ ] Extend ProcessManagement Request to call the correct interface or handle internal commands

Create script to setup new sonar cloud project for each microservice

Today we have the required sonar cloud configuration files but we don't call the rest endpoints to provision them. Allow this to be handled via the integrations resource type.

roadctl get integrations sonarcloud
roadclt create integrations sonarcloud -f sonarcreate.yaml

Add validation to tables in definitions file

https://github.com/pavedroad-io/roadctl/blob/create-cmd/src/roadctl/cmd/definitions.go

The roadctl create template read a definition.yaml file. In that file, a data object is specified using the Table structure. Each table contains a list/slice of columns. Columns consist of a name, mapped name, modifiers, and constraints.

Today, we have no validation of the types/contents of these fields.

Validation should be added as follows:

type should be a valid JSON value
modifiers should allow "omitempty", or "string" https://godoc.org/encoding/json
the mapped name should be the name as it will appear in JSON or YAML or;

  • "-," for a name represented as "-" in JSON

The TableType should be limited to JSONB

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.