Giter Site home page Giter Site logo

alexellis / jaas Goto Github PK

View Code? Open in Web Editor NEW
307.0 15.0 35.0 9.47 MB

Run jobs (tasks/one-shot containers) with Docker

Home Page: https://www.alexellis.io

License: MIT License

Go 72.43% Makefile 12.19% Dockerfile 5.57% Shell 9.81%
docker-swarm docker-api tasks services scheduling cron batch-jobs batch queue cluster

jaas's Introduction

Notice: archived

This project is archived, which means there are no plans for further development. If your company is using this in production, contact OpenFaaS Ltd for a commercial license and support. [email protected]

Jobs as a Service (JaaS)

Run jobs (tasks/one-shot containers) on Docker Swarm

This project provides a simple Golang CLI tool that binds to the Docker Swarm API to create an ad-hoc/one-shot Service and then poll until it exits. Service logs can also be retrieved if the Docker daemon API version is greater than 1.29 or if the experimental feature is enabled on the Docker daemon.

Build Status

Motivation and context

For a blog post covering use-cases for JaaS and more on the portions of the Docker API used see below:

Use-cases:

  • Use an elastic cluster as your computer
  • Clean up DB indexes
  • Send emails
  • Batch processing
  • Replace cron scripts
  • Run your server maintenance tasks
  • Schedule dev-ops tasks

Built for developers by developers

Sponsor this project

See also: Serverless

If you would like to build Serverless applications with Kubernetes or Docker Swarm checkout OpenFaaS:

The OpenFaaS project has dozens of contributors and thousands of GitHub stars - if you're here because you want to run short-lived functions then try it out today for asynchronous invocations, dashboards, scale-to-zero, and detailed metrics.

Sponsor this project ๐Ÿ†

If you want to see this project developed or are using it commercially, then please sponsor it here

Get started

Build and install the code

Pre-requisites:

  • Docker 1.13 or newer (experimental mode must be enabled if accessing service logs with Docker versions >= 1.13 and < 1.29)
  • Go 1.9.2 (or Golang container)
  • Enable Swarm Mode (docker swarm init)

Run these commands

# export GOPATH=$HOME/go
# go get -d -v github.com/alexellis/jaas
# cd $GOPATH/src/github.com/alexellis/jaas
# go install
# export PATH=$PATH:$GOPATH/bin

Now test jaas with jaas --help

Running a task / batch job / one-shot container

  • Run your first one-shot container with jaas run:
# jaas run -r --image alexellis2/cows:latest

The -r flag removes the Swarm service that was used to run your container.

The exit code from your container will also be available, you can check it with echo $?

  • Hiding logs

If you aren't interested in the output logs then run it with the --show-logs=false override:

# jaas run --image alexellis2/cows:latest --show-logs=false
  • Override the command of the container
# jaas run --image alpine:3.12 --command "uname -a"

Printing service logs
w2018-02-06T13:40:00.131678932Z Linux f56d298c4ab9 4.9.75-linuxkit-aufs #1 SMP Tue Jan 9 10:58:17 UTC 2018 x86_64 Linux

You can also try the example in examples/gotask:

# jaas run -r --image alexellis2/go-task:2020-03-11
  • Environment variables

Set environment variables with --env or -e:

# jaas run --image alpine:3.12 --env ENV1=val1 --env ENV2=val2 --command "env"

Service created: inspiring_elion (j90qjtc14usgps9t60tvogmts)
ID:  j90qjtc14usgps9t60tvogmts  Update at:  2018-07-14 18:02:57.147797437 +0000 UTC
...........

Exit code: 0
State: complete


Printing service logs
a2018-07-14T18:03:01.465983797Z PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
52018-07-14T18:03:01.466098037Z HOSTNAME=de0b5614fc88
)2018-07-14T18:03:01.466111965Z ENV1=val1
)2018-07-14T18:03:01.466122558Z ENV2=val2
*2018-07-14T18:03:01.466132520Z HOME=/root

Removing service...
  • Removing service after completion

By default, the service is removed after it completes. To prevent that, run with the --remove or -r flag set to false:

# jaas run --image alpine:3.12 --remove=false

Service created: zen_hoover (nwf2zey3i387zkx5gp7yjk053)
ID:  nwf2zey3i387zkx5gp7yjk053  Update at:  2018-07-08 20:19:39.320494122 +0000 UTC
............

Exit code: 0
State: complete


Printing service logs

# docker service ls

ID            NAME        MODE        REPLICAS  IMAGE       PORTS
nwf2zey3i387  zen_hoover  replicated  0/1       alpine:3.7
  • Docker authentication for registries

You can use jaas with Docker images in private registries or registries which require authentication.

Just run docker login then pass the --registry parameter and the encoded string you find in ~/.docker/config.json.

If you want to encode a string manually then do the following:

$ export auth='{
    "username" : "myUserName",
    "password" : "secret",
    "email" : "my@email",
    "serveraddress" : "my.reg.domain"
  }'
$ jaas run --registry="`echo $auth | base64`" --image my.reg.domain/hello-world:latest
  • Adding secret to service

To give the service access to an existing secret. run with the --secret or -s flag:

$ echo -n "S3_ACCESS_KEY_HERE" | docker secret create s3-access-key -
$ jaas run --image alpine:3.7 --secret s3-access-key --command "cat /run/secrets/s3-access-key"

Service created: priceless_tesla (f8gheat9f3b8cnnsjy9dth9y7)
ID:  f8gheat9f3b8cnnsjy9dth9y7  Update at:  2018-06-29 16:41:13.723257461 +0000 UTC
...........

Exit code: 0
State: complete

Printing service logs
(2018-06-29T16:41:19.057738088Z S3_ACCESS_KEY_HERE

Removing service...

Notes on images

You can have a multi-node swarm but make sure whatever image you choose is available in an accessible registry.

A local image will not need to be pushed to a registry.

  • Running jaas in a container

You can also run jaas in a container, but the syntax becomes slightly more verbose:

# docker run -ti -v /var/run/docker.sock:/var/run/docker.sock \
  alexellis2/jaas run --image alexellis2/cows:latest

Real-life example

You can use jaas to get the value of your OpenFaaS gateway password on Docker Swarm. See the OpenFaaS troubleshooting guide for the usage.

Roadmap:

Here are several features / enhancements on the roadmap, please make additional suggestions through Github issues.

  • Optionally delete service after fetching exit code/logs
  • Support passing environmental variables
  • Support private registry auth via -registryAuth flag
  • Move to cobra flags/args package for CLI
  • Support constraints on where to run tasks
  • Bind-mounting volumes
  • Overriding container command
  • Support optional secrets through CLI flag
  • Support environment variable files with --env-file

Todo:

  • Add support for running jobs on Kubernetes
  • Validation around images which are not in local library
  • Extract stdout/stderr etc from logs in human readable format similar to docker logs
  • Support incoming jobs API for Swarm

Future:

  • When task logs are available in the API this will be used instead of service logs.
  • When event streams are released they will prevent the need to poll continually

Similar tools

  • OpenFaaS - OpenFaaS runs CLIs, microservices and functions on Kubernetes with built-in asynchronous invocation support
  • faasd - faasd is a tiny version of OpenFaaS that runs CLIs and functions on a single node without Kubernetes
  • kjob by Stefan Prodan appears to be a close variation of jaas, but for Kubernetes.
  • argo workflows - argo workflows can be used to run tasks and pielines on Kubernetes

Contributions are welcome

See the contributing guide and do not raise a PR unless you've read it all.

jaas's People

Contributors

alexellis avatar ddingel avatar ikelutra avatar imumesh18 avatar johnharris85 avatar marcper avatar takafumikoyama 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  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

jaas's Issues

Prefixing services created by jaas

With a lot of created services it is useful to group services created by jaas.

Expected Behavior

jaas run --image hello-world

Service created: jaas_xenodochial_fermat (qvvqxyf120cbxjxoc8kdsw6fv)

Current Behavior

Currently the service name will be random. There is no way to identify which services were created by jaas.

Possible Solution

Set the name in the spec.

Steps to Reproduce (for bugs)

  1. jaas run --image hello-world
  2. docker service ls

Context

Use jaas on a docker swarm with long running services. If for some reason the jaas created services does not exit I want to identify that one.

Your Environment

  • Version used:
  • Environment name and version (e.g. Docker 1.13):
  • Server type and version:
  • Operating System and version:
  • Link to your project:

Feature: Add ability to specify command

Expected Behavior

jass --image bash --command ls -lha /

Current Behavior

Currently not possible to specify the command that you want the service to run.

Possible Solution

Will need the Command field adding to the ContainerSpec. Have started this but couldn't get it to work yet.

Context

I have a docker container that wraps a CLI program which has a signature like my_command process and my_command test. When I run using docker run docker run my_command_image process. My current work around is to modify the CLI script to use an environment variable but would be simpler to be able to specify the command. The other workaround would be to have specific docker images for each command but that adds a lot more work.

Let me know your thoughts? My two suggestions feel like we are duplicating more and more of the docker API which maybe is a bad thing? ๐Ÿคทโ€โ™‚๏ธ

Idea: add supports to env-file

As the classic service create command supports the --env-file argument to pass a file to load various env vars at time, add that option on jaas.

Expected Behavior

simply you can have a file like that:

var=foo
ver=fii

named env.env

so you can do:

jaas --env-file env.env -r local/myImage

Current Behavior

Currently you have to do that in a single line, and if you are testing or you have to call the command with a lot of envVars, could be a less readable line.

jaas -r -e var=foo -e ver=fii local/myimage

Context

I want to use jaas in a gitlab_ci job. The jaas excecution is inside a template, so I only want have to put all my vars in a env.file, and the template can handle the task, only passing to the jaas the env file.

Thanks!

Very awesome project!

Improve docs on --remove flag

Current Behavior

README.md doesn't say that a service is removed by default and the --remove flag example doesn't use the flag.

Expected Behavior

The docs should show an example with the non-default behavior, and it should be explained that services are removed by default.

Proposal: configure tasks via a YAML file instead of CLI

it would be very interesting to be able to run yaml files similar to docker-compose

 cron:
    networks:
      - sentry_sentry
    image: sentry:8.20.0
    command: "sentry cleanup -l WARNING --days 110"
    environment:
      SENTRY_POSTGRES_HOST: postgres
      SENTRY_DB_USER: sentry
      SENTRY_DB_PASSWORD: sentry
      SENTRY_REDIS_HOST: redis
    deploy:
      timeout: 60s
      remove: true
      placement:
        constraints:
          - node.labels.role == storage
    labels:
      com.xxx.service: "cron"
      com.xxx.stack: "sentry"
    logging:
      driver: gelf
      options:
        gelf-address: "udp://xxx"
        tag: "{{.ImageName}}/{{.ID}}/{{.Name}}"
        labels: "com.xxx.service,com.xxx.stack"

Installation error

When I execute go install, the bellow error appears:

# github.com/docker/docker/client
../../docker/docker/client/client.go:100: undefined: http.ErrUseLastResponse

Expected Behavior

I expect that the go install cmd just works :)

Current Behavior

root@swarm-manager-001:~# export GOPATH=$HOME/go

root@swarm-manager-001:~# apt install golang-go
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  golang-1.6-go golang-1.6-race-detector-runtime golang-1.6-src golang-race-detector-runtime golang-src
Suggested packages:
  bzr mercurial subversion
The following NEW packages will be installed:
  golang-1.6-go golang-1.6-race-detector-runtime golang-1.6-src golang-go golang-race-detector-runtime golang-src
0 upgraded, 6 newly installed, 0 to remove and 6 not upgraded.
Need to get 27.2 MB of archives.
After this operation, 198 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 golang-1.6-src amd64 1.6.2-0ubuntu5~16.04.2 [6,493 kB]
Get:2 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates/main amd64 golang-1.6-go amd64 1.6.2-0ubuntu5~16.04.2 [20.3 MB]
Get:3 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 golang-src amd64 2:1.6-1ubuntu4 [3,066 B]
Get:4 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 golang-go amd64 2:1.6-1ubuntu4 [21.8 kB]
Get:5 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 golang-1.6-race-detector-runtime amd64 0.0+svn252922-0ubuntu1 [404 kB]
Get:6 http://sa-east-1.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 golang-race-detector-runtime amd64 2:1.6-1ubuntu4 [2,854 B]
Fetched 27.2 MB in 3s (8,158 kB/s)                       
Selecting previously unselected package golang-1.6-src.
(Reading database ... 135894 files and directories currently installed.)
Preparing to unpack .../golang-1.6-src_1.6.2-0ubuntu5~16.04.2_amd64.deb ...
Unpacking golang-1.6-src (1.6.2-0ubuntu5~16.04.2) ...
Selecting previously unselected package golang-1.6-go.
Preparing to unpack .../golang-1.6-go_1.6.2-0ubuntu5~16.04.2_amd64.deb ...
Unpacking golang-1.6-go (1.6.2-0ubuntu5~16.04.2) ...
Selecting previously unselected package golang-src.
Preparing to unpack .../golang-src_2%3a1.6-1ubuntu4_amd64.deb ...
Unpacking golang-src (2:1.6-1ubuntu4) ...
Selecting previously unselected package golang-go.
Preparing to unpack .../golang-go_2%3a1.6-1ubuntu4_amd64.deb ...
Unpacking golang-go (2:1.6-1ubuntu4) ...
Selecting previously unselected package golang-1.6-race-detector-runtime.
Preparing to unpack .../golang-1.6-race-detector-runtime_0.0+svn252922-0ubuntu1_amd64.deb ...
Unpacking golang-1.6-race-detector-runtime (0.0+svn252922-0ubuntu1) ...
Selecting previously unselected package golang-race-detector-runtime.
Preparing to unpack .../golang-race-detector-runtime_2%3a1.6-1ubuntu4_amd64.deb ...
Unpacking golang-race-detector-runtime (2:1.6-1ubuntu4) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up golang-1.6-src (1.6.2-0ubuntu5~16.04.2) ...
Setting up golang-1.6-go (1.6.2-0ubuntu5~16.04.2) ...
Setting up golang-src (2:1.6-1ubuntu4) ...
Setting up golang-go (2:1.6-1ubuntu4) ...
Setting up golang-1.6-race-detector-runtime (0.0+svn252922-0ubuntu1) ...
Setting up golang-race-detector-runtime (2:1.6-1ubuntu4) ...
root@swarm-manager-001:~# go get -d -v github.com/alexellis/jaas
github.com/alexellis/jaas (download)
github.com/docker/docker (download)
Fetching https://golang.org/x/net/context?go-get=1
Parsing meta tags from https://golang.org/x/net/context?go-get=1 (status code 200)
get "golang.org/x/net/context": found meta tag main.metaImport{Prefix:"golang.org/x/net", VCS:"git", RepoRoot:"https://go.googlesource.com/net"} at https://golang.org/x/net/context?go-get=1
get "golang.org/x/net/context": verifying non-authoritative meta tag
Fetching https://golang.org/x/net?go-get=1
Parsing meta tags from https://golang.org/x/net?go-get=1 (status code 200)
golang.org/x/net (download)
root@swarm-manager-001:~# cd $GOPATH/src/github.com/alexellis/jaas

root@swarm-manager-001:~/go/src/github.com/alexellis/jaas# go install
# github.com/docker/docker/client
../../docker/docker/client/client.go:100: undefined: http.ErrUseLastResponse

Steps to Reproduce (for bugs)

Use a ubuntu 16.04.2 LTS in AWS and execute those commands above.

Context

I'm just trying to install jaas

Your Environment

  • Version used: master
  • Environment name and version (e.g. Docker 1.13):
# docker info
Containers: 3
 Running: 2
 Paused: 0
 Stopped: 1
Images: 5
Server Version: 17.05.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge host ipvlan macvlan null overlay
Swarm: active
 NodeID: 2rwbd9ahxva8si2myapzf2r1q
 Is Manager: true
 ClusterID: 3d9f0pk0ofuye8vnub8p273b1
 Managers: 3
 Nodes: 7
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 3
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
 Node Address: 10.0.1.101
 Manager Addresses:
  10.0.1.101:2377
  10.0.2.102:2377
  10.0.3.103:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9048e5e50717ea4497b757314bad98ea3763c145
runc version: 9c2d8d184e5da67c95d601382adf14862e4f2228
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-78-generic
Operating System: Ubuntu 16.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.858GiB
Name: swarm-manager-001
ID: PT4G:CMUG:DDRH:M45E:OTTE:ESJD:TGPA:SJHA:6GN4:TZ66:HSDM:LCCR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
 os=linux
 region=sa-east-1
 availability_zone=sa-east-1a
 proxy=true
 postgres=master
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
  • Server type and version: AWS Ec2
  • Operating System and version:
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.2 LTS
Release:	16.04
Codename:	xenial

ENHANCEMENT : Follow logs tail style

Hello,

Current Behavior

In current version, the logs are displayed once the service has terminated
While the service is executing, the Jaas command only outputs some dots

For example:

"
[truncated output]
Service created: vibrant_mcclintock (4p4vy93tij38fhbxqyrgp6rt8)
ID: 4p4vy93tij38fhbxqyrgp6rt8 Update at: 2018-11-08 15:47:32.340267998 +0000 UTC
...

Exit code: 0
State: complete

Printing service logs
$2018-11-08T15:47:33.547861076Z dummy
"

The command executed was "echo dummy"

Possible Solution

It would be nice having a "--follow" option in the style of "tail" or other utilities, so the logs are streamed to the standard output and displayed in tools that launch the Jaas command

Steps to Reproduce (for bugs)

Not really a bug, but here is how I launch the command :
/root/jaas run -t=120s --remove=true --show-logs=true --verbose=true --image ubuntu:latest --command "echo dummy"

Context

Trying to use Jaas as a way of launching batch containers synchronously on a Swarm cluster.
The โ€œsynchronouslyโ€ word is important, I am running these containers from a Jenkins instance, and which that the Jenkins Job does stream the containerโ€™s logs to the standatd output and stops when the container has stopped.

Thank you for your help / advice

Feature: Add env file support

Expected Behavior

jaas run --env-file .env -image alexellis2/href-counter:latest

Current Behavior

Currently if you have a number of environment variables you need to specify them all on the command line.

Possible Solution

Currently working copy here: https://github.com/IkeLutra/jaas/tree/addEnvFileSupport

Issues with this solution are:

  • Imports all of docker cli for one function (could use https://github.com/joho/godotenv instead for parsing envfile)
  • Some code has been copied from docker/cli repo (Are licenses compatible? or should it just be rewritten?)

Advice would be appreciated.

Context

I have a couple of images which I pass up to 10 environment variables to. Would be simpler to use a .env file so I don't have to copy and paste them when ever I run jaas commands.

Job waits timeout on task failure

Note: Maybe it's an expected behavior

Expected Behavior

I think the job may finish as soon as the task is terminated to get logs and RC

Current Behavior

The job waits timeout if the task finish early with error code != 0

Possible Solution

Break the wait loop if the status is like "State":"failed"

Steps to Reproduce (for bugs)

Job with RC 0 OK:
echo -e 'FROM alpine\nCMD ["ls"]' | docker build -t wtf - && ./jaas run -r -i wtf
Job with RC != 0, waits 60 ticks:
echo -e 'FROM alpine\nCMD ["ls","bad"]' | docker build -t wtf - && ./jaas run -r -i wtf

Context

Just testing !

Your Environment

  • Version used: commit afb552b
  • Environment name and version (e.g. Docker 1.13): docker 17.09.0-ce

Bug: Experimental Daemon no longer required for service logs

Expected Behavior

As docker service logs is no longer experimental as of Docker API v1.29, jaas shouldn't require it for --showlogs=true to work. (https://docs.docker.com/engine/reference/commandline/service_logs/)

Current Behavior

Currently experimental mode is required even on new versions of docker.

Possible Solution

Presumably this would be an easy modification of this if statement (

jaas/app.go

Line 77 in ba68947

if versionInfo.Experimental == false {
) to detect if you have a high enough version to not enable experimental mode.

Steps to Reproduce (for bugs)

  1. Run jaas -rm -image alexellis2/cows:latest --showlogs=true on a Docker Daemon without experimental mode enabled
  2. Will return error message "Experimental daemon required to display service logs, falling back to no log display."

Context

I would prefer not to enable experimental mode if possible as I assume it is less stable? Correct me if I am wrong.

Your Environment

  • Version used: b57a80e
  • Environment name and version (e.g. Docker 1.13): Docker 17.12.0-ce (API v1.35)
  • Server type and version: Azure VM
  • Operating System and version: Ubuntu 17.04

Caveat

I haven't dug into your code a lot so am unsure if you are using some experimental extensions to docker service logs that aren't yet available in the stable api. Also realise I am talking about the CLI commands rather than the API methods but I think they are both available?

Thanks for your time

Idea: Provide jaas run with compose file and service name for service creation

Expected Behavior

Command docker stack deploy gets service information from a docker-compose.yml file. The idea is for jaas run to be able to get the service specification from the same source.

Current Behavior

jaas run requires all service information to be passed directly via the command line (except for the env files).

Possible Solution

A new flag for jaas with the path to a compose file and the service name. For example

# jaas run -f docker-compose.yml=my_service --command "./run-migrations.sh"

Context

The most common use case of jaas for me is running Database migrations, just before deploying a stack that depends on them. These migrations are always part of the code that is to be deployed and the one-shot service needs the same environment and secrets as the actual swarm service.

So, the service is for me always necessarily configured already by docker-compose.yml and it holds all the information that jaas needs to run. If jaas could read it from the source, there wouldn't be a need for duplicating it.

[Improvement] Always remove when requested

Expected Behavior

When jaas terminates, for any reason (timeouts or the user cancels the task with CTRL-C for example), the service created should be removed so that, no "garbage" is left behing
If the flag --remove asks otherwise, don't remove the service

Current Behavior

When running a task, if the task timeouts or the user cancels the task with CTRL-C for example, the service will remaining and won't be removed

Possible Solution

From what I could understand in the code, the ServiceRemove function is only called when everything went "fine" (or at least, the service "finished" somehow):

	stopStates := []swarm.TaskState{
		swarm.TaskStateComplete,
		swarm.TaskStateFailed,
		swarm.TaskStateRejected,
	}

The solution could be that the ServiceRemove function is called when the jaas process "stops" (CTRL-C must be captured) or the task timeouts.

Steps to Reproduce (for bugs)

  1. docker -H "ssh://<manager>" run --rm -it -v /var/run/docker.sock:/var/run/docker.sock alexellis2/jaas run -r --image alexellis2/cows --timeout 1s
  2. docker service ls will give sth like:
ID                  NAME                                    MODE                REPLICAS            IMAGE                                                                      PORTS
z9y5v33nohdo        dreamy_sammet                           replicated          0/1                 alexellis2/cows:latest
  1. And docker service ps dreamy_sammet
ID                  NAME                IMAGE                    NODE                DESIRED STATE       CURRENT STATE             ERROR               PORTS
prcz9a29sd9z        dreamy_sammet.1     alexellis2/cows:latest   db-001              Shutdown            Complete 14 seconds ago
  1. You see the desired state so the service is still there :)

Context

Either a task can timeout for several reason or the user might cancel the request because of a mistake or even, there is a problem with the docker daemon that cause the service/task to be stuck in "Preparing" state.

All these reasons leaves "service zoombie" behinds

Your Environment

  • Version used: (latest from hub.docker.com)
  • Environment name and version (e.g. Docker 1.13): Docker version 19.03.12, build 48a66213fe
  • Server type and version: VM Linux 4.19.0-10-cloud-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
  • Operating System and version: Linux 4.19.0-10-cloud-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
  • Link to your project: N/A

Support sending registry auth

I run cron in a container. The cron would run Jaas. In order for the jaas service to pull a private image we'd need to send the registry login via jaas.

Expected Behavior

Accepts registry auth as cli option and allows use of private images

Current Behavior

Can't use private image if run via docker

Add support for volume mounts

Expected Behavior

It would be useful to be able to support volume mounts rather than just bind mounts, as it lets you use a wider variety of volume drivers.

Current Behavior

Only bind mounts are supported

Possible Solution

The following change to the code seems to work (I'm new to Go so feel free to suggest a better way of formatting it):
Old:

if len(parts) == 2 {
			mountVal := mount.Mount{
				Source: parts[0],
				Target: parts[1],
			}

			spec.TaskTemplate.ContainerSpec.Mounts = append(spec.TaskTemplate.ContainerSpec.Mounts, mountVal)
		}

New:

if len(parts) == 2 {
                        mountVal := mount.Mount{}
                        if strings.HasPrefix(parts[0], "v:") {
                                mountVal = mount.Mount{
                                        Type: mount.TypeVolume,
                                        Source: strings.TrimLeft(parts[0], "v:"),
                                        Target: parts[1],
                                }
                        } else {
                                mountVal = mount.Mount{
                                        Source: parts[0],
                                        Target: parts[1],
                                }
                        }
                        spec.TaskTemplate.ContainerSpec.Mounts = append(spec.TaskTemplate.ContainerSpec.Mounts, mountVal)
                }

Then, if I want to use a named volume pass in:

-m "v:volumeName=/mnt/somewhere"

Context

I want to use JaaS with persistent volumes created by the Docker Swarm Cloudstor drivers.

Your Environment

  • Version used: master
  • Environment name and version (e.g. Docker 1.13): Docker CE 19.03.5
  • Server type and version: Ubuntu 18.04LTS

Please consider adding support for setting the mode for secrets

I want to run job, that will use do a git pull via ssh. I pass in the ssh private key via a secret ssh fails, since the permissions are 0444. Other software things that use secrets might check the permissions.

jaas run  --verbose \
          --image myimage \
          --secret 20190309_ed25519 \
          --command "/srv/myjob.sh"

...6427Z @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...7126Z @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
...3926Z @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...9526Z Permissions 0444 for '/run/secrets/20190309_ed25519' are too open.
...4826Z It is required that your private key files are NOT accessible by others.
...0226Z This private key will be ignored.

bug: the --verbose (-b) flag isnt working

When you add the --verbose command to your execution, it doesn't display more information comparing with the regular run of the jaas.

Expected Behavior

The idea is that when you add that flag, more information about your run appear on the console; things like that you can found at pkg/swarm/task.go like these:

fmt.Printf("Running.. OK %s\n", taskRequest.Image)
		fmt.Printf("Connected to.. OK %s\n", taskRequest.Networks)
		fmt.Printf("Constraints: %s\n", taskRequest.Constraints)
		

but anything of that are visible on the output.

Current Behavior

If you add the --verbose flag, it works like the regular run.
Saying service created, with the corresponding id and name, the log if --show-log is true, the exit code and the use of auth if you use -a flag.

Possible Solution

Is really a silly bug; if you read the pkg/swarm/task.go, when the programs checks of the --verbose flag, it try to find it on taskRequest.Verbose, like on these lines:

if taskRequest.Verbose {
		fmt.Printf("Running.. OK %s\n", taskRequest.Image)
		fmt.Printf("Connected to.. OK %s\n", taskRequest.Networks)
		fmt.Printf("Constraints: %s\n", taskRequest.Constraints)
		fmt.Printf("envVars: %s\n", taskRequest.EnvVars)
		fmt.Printf("Secrets: %s\n", taskRequest.Secrets)
	}

	

but if you check cmd/run.go, you can notice that the --verbose flag is only setting a local verbose bool; not the taskRequest.verbose flag:

var (
	taskRequest jtypes.TaskRequest
	verbose     bool
)
runCmd.PersistentFlags().BoolVarP(&verbose, "verbose", "b", false, "print verbose debug information")

I don't found anything other change that will be necesary.

Steps to Reproduce (for bugs)

Simply do a run with jaas; one using -b and other not. with the same parameters; you don't see any different.

Context

I want to simply see with more details the things that are happening on the underground, to check errors, and have a more detailed output.

Your Environment

  • Version used: latest git commit.
  • Environment name and version (e.g. Docker 1.13): docker 19.03.13 on local environment, and latest docker binary on the alpine repository on custom images.

This!

I found the issue, but I don't know if affect other parts of the project, so, I preffer to report it instead of end a pull request.
And well, I don't know how to send a pull request here on github jaja ๐Ÿ˜„
Thanks for all Alexellis!

question: how use authentication for v2 registries

hello guys, is a small question; what is the correct way to pass a registry token to the jaas when the token is for a v2 registry?

After log-in to the registry with the docker login command, the result in config.json file have this schema:

{
"auths": {
"my.registry.domain": {
"auth": "ALargeStringWithData"
}
},
"HttpHeaders": {
"User-Agent": "Docker-Client/19.03.12 (linux)"
}

I don't know with value I have to pass to the --registry flag. Is the entire file encoded in base64? only the large string under the domain key? Or the same value but encripted?

Thanks guys ๐Ÿ˜„ ๐Ÿ˜ƒ

No logs displayed when launched command is in error

Hello,

Current Behavior

In current version, no logs are displayed when the launched command exits with an error.

Expected Behavior

I would expect the command output to be displayed in all cases

Steps to Reproduce (for bugs)

From inside the JAAS container:
/root/jaas run -t=120s --remove=true --show-logs=true --verbose=true --image ubuntu:latest --command "dummy"

output :
"
... truncated ...
Exit code: 0
State: rejected

Printing service logs

Removing service...
"

I would expect something like
... truncated ...
Printing service logs
/bin/sh: dummy: not found
"

Possible solution

Maybe this is due to the comand outputing data to stderr instead of standard output ?

Your Environment

  • JAAS version
    ~ # /root/jaas version


    | | __ _ __ / |
    _ | |/ |/ _ _

    | |
    | | (
    | | (
    | |) |
    _
    / _
    ,|_,|___/

Commit: 53ea90c
Version: dev

  • docker --version
    Docker version 18.06.1-ce, build e68fc7a

Thanks for your help / advice

Idea: API/remote server component

Building an API or remote/server component could be useful for some use-cases around batching. This could also decouple slightly from Swarm allowing other back ends to be built into the binary such as Kubernetes.

Considerations:

  • Some level of authentication would be needed such as TLS or basic auth.
  • API design - parity with jaas run is a good start, generic object model would be ideal
  • For simplicity the changes may require server component to run in background even for "local" calls
  • a 1.0 release should be cut first

Idea: binary releases on GitHub

How are you using jaas? Would it be useful to have a binary release and curl script / brew formula or do you run it inside the Docker container I am providing?

Cannot show logs with API version 1.29

With docker with API version 1.29, showing logs is not possible.

Expected Behavior

jaas run shows logs.

Current Behavior

jaas run fails when command line arguments say it should show logs.

Possible Solution

The version number string is parsed as float and later compared with 1.29, which fails to pass "1.29". Fixing comparison will fix the issue.

> github.com/alexellis/jaas/cmd.runTask() /home./go/src/github.com/alexellis/jaas/cmd/run.go:110 (PC: 0x914524)                                                                                                                                                                                                                                                                                                                           
   105:                                                                                                                                                                                                                                                                                                                                                                                                                                   
   106:                 return versionErr                                                                                                                                                                                                                                                                                                                                                                                                 
   107:         }                                                                                                                                                                                                                                                                                                                                                                                                                         
   108:                                                                                                                                                                                                                                                                                                                                                                                                                                   
   109:         if taskRequest.ShowLogs {                                                                                                                                                                                                                                                                                                                                                                                                 
=> 110:                 apiVersion, parseErr := strconv.ParseFloat(versionInfo.APIVersion, 32)                                                                                                                                                                                                                                                                                                                                            
   111:                 if parseErr != nil {                                                                                                                                                                                                                                                                                                                                                                                              
   112:                         apiVersion = 0                                                                                                                                                                                                                                                                                                                                                                                            
   113:                 }                                                                                                                                                                                                                                                                                                                                                                                                                 
   114:                 if apiVersion < 1.29 && versionInfo.Experimental == false {                                                                                                                                                                                                                                                                                                                                                       
   115:                         return fmt.Errorf("experimental daemon or Docker API Version 1.29+ required to display service logs, falling back to no log display")                                                                                                                                                                                                                                                                     
(dlv) p versionInfo.APIVersion                                                                                                                                                                                                                                                                                                                                                                                                            
"1.29"                                                                                                                                                                                                                                                                                                                                                                                                                                    
(dlv) n                                                                                                                                                                                                                                                                                                                                                                                                                                   
> github.com/alexellis/jaas/cmd.runTask() /home./go/src/github.com/alexellis/jaas/cmd/run.go:111 (PC: 0x9145b1)                                                                                                                                                                                                                                                                                                                           
   106:                 return versionErr                                                                                                                                                                                                                                                                                                                                                                                                 
   107:         }                                                                                                                                                                                                                                                                                                                                                                                                                         
   108:                                                                                                                                                                                                                                                                                                                                                                                                                                   
   109:         if taskRequest.ShowLogs {                                                                                                                                                                                                                                                                                                                                                                                                 
   110:                 apiVersion, parseErr := strconv.ParseFloat(versionInfo.APIVersion, 32)                                                                                                                                                                                                                                                                                                                                            
=> 111:                 if parseErr != nil {                                                                                                                                                                                                                                                                                                                                                                                              
   112:                         apiVersion = 0                                                                                                                                                                                                                                                                                                                                                                                            
   113:                 }                                                                                                                                                                                                                                                                                                                                                                                                                 
   114:                 if apiVersion < 1.29 && versionInfo.Experimental == false {                                                                                                                                                                                                                                                                                                                                                       
   115:                         return fmt.Errorf("experimental daemon or Docker API Version 1.29+ required to display service logs, falling back to no log display")                                                                                                                                                                                                                                                                     
   116:                 }                                                                                                                                                                                                                                                                                                                                                                                                                 
(dlv) p apiVersion                                                                                                                                                                                                                                                                                                                                                                                                                        
1.2899999618530273  

Steps to Reproduce (for bugs)

  1. Install docker 17.05
  2. jaas run -i hello-world

Context

I'm using docker 17.05 and jaas fails to run without '--show-logs=false' option.

Your Environment

  • Version used: dev (6ad1e6a)
  • Environment name and version (e.g. Docker 1.13): Docker 17.05
  • Server type and version:
  • Operating System and version: Ubuntu 16.04
  • Link to your project:

feature: let change the log-driver with a flag

The idea, is let the user select the log driver that he wants to use on he's jaas execution.
In some cases the docker daemon have as default a log-driver that didn't work for your one shot container.
That was my case.

Expected Behavior

Add a option (for example --log-driver) that force the created service to use that log driver instead the default that the connected daemon has.

Current Behavior

Currently you can't change with jaas the log-driver to use on the execution. Jaas uses the default log-driver that is setted on the machine that you are connected, so for example in my case, I needed use json-file drive to get the logs in jaas, but my machine have gelf as default and with jaas I didnt have any method to change.
I had to fork the project, and in the makeSpect method of task.go, y manually setted the LogDriver to json-file and works like a charm.

Possible Solution

Add an alternative --log-driver flag, that set that log-driver on the execution; if the flag is missing, dont add to the spect a logDriver and use the default of the docker daemon.

Context

I created a alpine image that contains a docker client, and jaas. With that, I connect to mi swarm clusters (using docker machine) to execute one shot containers.
The problem is, that I want see the direct output of my execution on my pipelines with jaas, but for that, I need to use json-file as a log-driver; but these machines as default use the gelf driver and I cant modify it only for the execution.

Replace vendor tool vndr with dep.

Description

I seen the to-do. It has migrating the repo to dep from vndr. So I have few questions.

  • Should I add latest version or the version specified in the vendor.conf?
  • As I couldn't find any other problems migrating to dep, so if anyone knows any can you just list it here.

Cc / @alexellis

P.S I would like work on this. So please suggest anything if I have missed it.

Feature request: Support service placement constraints

Would be useful to be able to specify that ad-hoc jobs should only happen on specific nodes (using existing service --constraint syntax?). For example, some task should happen on all database nodes, or all RHEL nodes, etc...

Support Hyper.sh as backend driver

Hyper.sh as backend driver

Expected Behavior

It would be great to support Hyper.sh or ACI as backend driver

Current Behavior

Need a VM cluster

Possible Solution

Hyper.sh API is consistent with Docker.

Steps to Reproduce (for bugs)

Context

Ad-hoc jobs without infrastructure, per-second billing

Your Environment

  • Version used:
  • Environment name and version (e.g. Docker 1.13):
  • Server type and version:
  • Operating System and version:
  • Link to your project: hyper.sh

Run command is not unit tested

Expected Behavior

Ideally, the main command run should be unit tested.

Current Behavior

There are no unit tests for jaas run.

Possible Solution

Create unit tests for the service spec creation, checking if given input flags lead to the right service settings.

Your Environment

  • Version used: dev
  • Go version: 1.10.3
  • Environment name and version: Docker 17.12.0-ce, Docker API 1.35
  • Operating System and version: Ubuntu 18.04

Feature: Support swarm secrets

Pre-existing secrets should be able to be referenced from the JaaS task

Expected Behavior

jaas run --secret oauth_token --secret developer_token alexellis2/github:scrape

Current Behavior

Secrets are not supported.

Possible Solution

Write code for this feature.

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.