choria-io / go-backplane Goto Github PK

View Code? Open in Web Editor NEW

15.0 15.0 4.0 242 KB

A embeddable management backplane for your Go application

License: Apache License 2.0

Go 94.22% Shell 0.96% Ruby 3.73% Dockerfile 1.08%

go-backplane's People

Contributors

Stargazers

Watchers

Forkers

rjw1 happy-ferret ripienaar jmptrader

go-backplane's Issues

Move to using mcorpc-agent-provider/client

Client has left go-choria and is now its own thing

add a way to view facts for a specific instance

right now discoverabilty of what facts can be filtered on is basically zero

--help is broken

% backplane --help
usage: backplane [<flags>] <command> [<args> ...]

Choria Backplane

Flags:
      --help     Show context-sensitive help (also try --help-long and
                 --help-man).
      --version  Show application version.
  -v, --verbose  Enable verbose output
  -d, --debug    Enable debug logging

Commands:
  help [<command>...]
    Show help.

  exec* [<flags>] <service> <action>
    Executes a action against a set of backplane managed services

fine, but try as I might i cant get the detailed exec help, all basically ends in

% backplane help exec
backplane: error: enum value must be one of pause,resume,flip,health,shutdown,ping,info, got 'exec', try --help

example

I just found this project and have been playing aroudn with it. It really adds allot of the stuff you need in ops and i like its approach. no more ssh bastions and guesswork etc :)

Is it possible to make an example to show off Choria for a golang apps developer ?

Maybe a docker for the core choria server with the certs setup and then a microservice using the backplane.

https://github.com/purpleidea/mgmt

This uses a graph to map code together so its reactive.

Reminds me a bit of what your doing, but using NATS.

https://github.com/purpleidea/mgmt

Figured its worth just listing here as there is heavy crossover in that this is meant to replace Puppet

improve error handling during initialization

at present if a app that embeds the backplane gets ^C'd during its initial connection a nil pointer deref is done

ERRO[0003] Initial NATS connection failed: Could not create connector: Initial connection cancelled due to shut down  component=server identity=dev1.devco.net
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x835372]

goroutine 1 [running]:
.../choria-cron/vendor/github.com/choria-io/go-choria/server/agents.(*Manager).RegisterAgent(0x0, 0xaaebe0, 0xc420254000, 0xa367a7, 0xb, 0xaaef20, 0xc4200a4c40, 0x7fd471d7dc30, 0xc42042dc00, 0x0, ...)
        /home/rip/go/src/.../choria-cron/vendor/github.com/choria-io/go-choria/server/agents/agents.go:89 +0x42
.../choria-cron/vendor/github.com/choria-io/go-choria/server.(*Instance).RegisterAgent(0xc4202601b0, 0xaaebe0, 0xc420254000, 0xa367a7, 0xb, 0xaaef20, 0xc4200a4c40, 0x0, 0x0)
        /home/rip/go/src/.../choria-cron/vendor/github.com/choria-io/go-choria/server/instance.go:103 +0xbe
.../choria-cron/vendor/github.com/choria-io/go-backplane.(*Management).startAgents(0xc4203dcc90, 0xaaebe0, 0xc420254000, 0xc420023070, 0x0)
        /home/rip/go/src/.../choria-cron/vendor/github.com/choria-io/go-backplane/agent.go:91 +0x342

This is unavoidable until choria-io/go-choria#361 is fixed

Running Demo with docker: cli not starting

Cant get the CLI to connect to the Docker ...
Am not a docker expert. Bet its a silly things i am not doing...

Following the readme ...

server up - all good:

make run-docker-server
cd /Users/apple/workspace/go/src/github.com/choria-io/go-backplane &&  docker-compose up --scale demo1=2 --scale demo2=2
Starting go-backplane_broker_1 ... done
Starting go-backplane_demo2_1  ... done
Starting go-backplane_demo2_2  ... done
Starting go-backplane_demo1_1  ... done
Starting go-backplane_demo1_2  ... done
Attaching to go-backplane_broker_1, go-backplane_demo2_1, go-backplane_demo2_2, go-backplane_demo1_1, go-backplane_demo1_2
broker_1  | [1] 2018/07/13 14:01:10.848940 [INF] Starting nats-server version 1.2.0
broker_1  | [1] 2018/07/13 14:01:10.848994 [INF] Git commit [6608e9a]
broker_1  | [1] 2018/07/13 14:01:10.849098 [INF] Starting http monitor on 0.0.0.0:8222
broker_1  | [1] 2018/07/13 14:01:10.849141 [INF] Listening for client connections on 0.0.0.0:4222
broker_1  | [1] 2018/07/13 14:01:10.849161 [INF] Server is ready
broker_1  | [1] 2018/07/13 14:01:10.849469 [INF] Listening for route connections on 0.0.0.0:6222

cli up - not os good...


x-MacBook-Pro:choria apple$ make run-docker-cli
docker run -e BROKER=192.168.1.119:4222 backplane --insecure demo2 info
Unable to find image 'backplane:latest' locally
docker: Error response from daemon: pull access denied for backplane, repository does not exist ormay require 'docker login'.
See 'docker run --help'.
make: *** [run-docker-cli] Error 125

go get failing...

go get -u github.com/choria-io/go-backplane/...
# github.com/choria-io/go-choria/choria
../../../../../../github.com/choria-io/go-choria/choria/framework.go:474:35: multiple-value uuid.NewV4() in single-value context
make: *** [dep] Error 2

publish a mcollective module with the client files

create backplane cli

I reckon the best is if instead of allowing the agent name to be changed we standardise to backplane, we then create a CLI in go that gets released. It also avoids all the insanity with DDL files

This hugely reduce the on boarding surface area since someone then just need to backplane enroll and once they are on the network can manage their microservices with no ruby stuff needed at all.

In time once a choria CA exist this will create a very low friction setup - one that can even be started from a docker compose file in its entirity

update to latest choria client conventions

fix generated DDL

The generated DDL have several issues:

Syntax errors
health_feature should be healthcheck_feature

fix agent to backplane
do not make collective directly configurable
make name configurable and derive name_backplane subcollective
validate the combinarion is a valid subcollective name
update docs
remove --name from generate

Follow up with:

remove generate entirely and make a generic client module on the forge with the DDLs baked in