Giter Club home page Giter Club logo

app's Introduction

⚠️ Deprecation Notice: This project and repository is now deprecated and is no longer in active development, see the related roadmap issue. If you'd like to continue using CNAB for packaging your applications, check out Porter.

Docker App

Docker App is a Cloud Native application packaging framework with which developers and devops can build, share, and run a set of microservices as a single entity. Docker Apps are based on the Compose format, which permits docker-compose users to easily share their Compose-based multiservice applications via container registries. By leveraging containers, Docker App makes it possible to easily change parts of the application and to share the application through container registries.

Table of Contents

What are the benefits offered by Docker App?

  • Simple management of Docker Apps across different teams and between different environments (Development/QA/Staging/Production)
  • Easy sharing of multi-service applications to container registries (e.g., Docker Hub or Docker Trusted Registry)
  • Having a clear separation of parameters to be modified at runtime
  • Support for multiple orchestrators (Swarm or Kubernetes)
  • Provides the very same UX flow as the one for Docker images
  • Implements the CNAB industry standard
  • Offers full support for Docker Contexts

How does Docker App work?

The Docker App workflow is quite similar to the Docker image workflow. From an App definition, you can build an App image, share it on Docker Hub, and run your App on an orchestrator.

Image showing Docker CLI command flow

Using Docker App

Four primary steps comprise the Docker App process:

  1. Writing an App Definition
  2. Building an App Image
  3. Sharing the App on the Hub (optional)
  4. Running the App

Writing an App definition

The first step in using Docker App is to write the App definition. This definition can be created (1) from an existing Compose file using the docker app init command (2) via a template from the Application Designer, or (3) from scratch.

The App definition is a .dockerapp folder that contains three distinct pieces: metadata, a service list, and the parameters.

File Description
metadata.yml metadata including the App name and version
docker-compose.yml Service list defined in a Compose file
parameters.yml Parameters that can be changed when running the App

*Note: To store additional files in Docker Apps, such as prod.yml, test.yml or other config files, you need only to add these files to the .dockerapp directory. All files will be packaged into the App image through the use of the docker app build command.

Building an App image

Once the App definition is written, the next step is to build the App image from the App definition using the docker app build command. With this command you can tag your App image, set build-time variables, or make the build quiet.

Note that service images inside of an App image are immutable, meaning that the App version ties to a fixed list of service images (i.e., updating the images inside of a Docker App requires rebuilding the App image). This makes deploying applications more deterministic.

Sharing the App on the Hub

You can push any App image already built or pulled to Docker Hub (or any OCI compliant registry) using the docker app push command. You can also pull App images from any OCI compliant registry using the docker app pull command.

When pushing an App image, all the service images used by the application are pushed at the same time inside a single entity. The version of each service image is resolved at build time from its tag.

Running the App

The final Docker App step is to actually run your App using the docker app run command. You can either pick up an App image from Docker Hub or one that you built locally and deploy it to Swarm or Kubernetes.

Example

Using the hello-world application example, we are going to build, share, and run a Docker App that launches an HTTP server that prints the text variable value when hit on the configured port.

Note: Before starting, confirm that the Docker App CLI plugin is installed on your machine

App definition

First, create an App definition from an existing Compose file.

Create a docker-compose.yml file that has the following content:

version: '3.6'
services:
  hello:
    image: hashicorp/http-echo
    command: ["-text", "hello world"]
    ports:
      - 5678:5678

Next, create an App definition using the docker app init command:

$ docker app init --compose-file docker-compose.yml hello
Created "hello.dockerapp"
$ tree
.
├── docker-compose.yml
├── hello.dockerapp
    ├── docker-compose.yml
    ├── metadata.yml
    └── parameters.yml

A new folder named hello.dockerapp now exists, which contains three YAML documents:

  • metadata
  • a Compose file
  • parameters for your application to be used at runtime

The metadata.yml file should display as follows:

version: 0.1.0
name: hello
description: A simple text server
maintainers:
- name: yourusername
  email:

The Compose file is the one that was passed in parameters. Thus, if you open parameters.yml you will notice that it is empty, as the Compose file isn’t using any variable.

Using parameters

Edit the docker-compose.yml file in the hello.dockerapp directory to add some variables:

version: '3.6'
services:
  hello:
    image: hashicorp/http-echo
    command: ["-text", "${text}"]
    ports:
      - ${port}:5678

Next, define the default values for the App in the parameters.yml file:

port: 5678
text: hello development

Building an App image

Next, build an App image:

$ docker app build . -f hello.dockerapp -t myrepo/hello:0.1.0
[+] Building 0.7s (6/6) FINISHED
(...) (Build output)
sha256:4a492748ae55170daadd1ddfff4db30e0ef3d38bf0f57a913512caa323e140de

At this point, an App image with the myrepo/hello:1.0.1 tag has been built from the hello.dockerapp App definition. This immutable App image includes all the service images at fixed versions that you can run or share.

Sharing and running the App

To share your App image, push it to a container registry.

$ docker app push myrepo/hello:0.1.0

Now run your App:

$ docker app run myrepo/hello:0.1.0 

You can specify the Docker endpoint where an application is installed using a context. By default, your App will run on the currently active context. You can select another context with the docker context use command, and the docker app run command will thereafter run your app on this particular context.

Whenever you define such a context, the installer image will run in the default context (i.e., on local host). You can then use the --installer-context to target another context to run the installer image.

$ docker context create remote --description "remote cluster" --docker host=tcp://<remote-ip>:<remote-port>
Successfully created context "remote"

$ docker context ls
NAME                DESCRIPTION                               DOCKER ENDPOINT               KUBERNETES ENDPOINT                ORCHESTRATOR
default *           Current DOCKER_HOST based configuration   unix:///var/run/docker.sock   https://localhost:6443 (default)   swarm
remote              remote cluster                            tcp://<remote-ip>:<remote-port>

$ docker context use remote
$ docker app run myrepo/hello:0.1.0

CNAB

Docker Apps are Docker’s implementation of the industry standard Cloud Native Application Bundle (CNAB). CNAB is an industry specification put in place to facilitate the bundling, sharing, installing and managing of cloud-native apps that are not only made up of containers but also from such things as hosted databases, functions, etc. Docker App is designed to abstract as many CNAB specifics as possible, to provide users with a tool that is easy to use while alleviating the need to bother with the CNAB specification.

Installation

Docker App is a command line plugin (not be confused with docker engine plugins) that extends the docker command with app sub-commands. It requires Docker CLI 19.03.0 or later, with experimental features enabled. Either set environment variable DOCKER_CLI_EXPERIMENTAL=enabled or update your docker CLI configuration.

Note: The docker plugin install command cannot be used to install Docker-app.

Linux or macOS

Download your OS tarball:

export OSTYPE="$(uname | tr A-Z a-z)"
curl -fsSL --output "/tmp/docker-app-${OSTYPE}.tar.gz" "https://github.com/docker/app/releases/download/v0.8.0/docker-app-${OSTYPE}.tar.gz"
tar xf "/tmp/docker-app-${OSTYPE}.tar.gz" -C /tmp/

Install as a Docker CLI plugin:

mkdir -p ~/.docker/cli-plugins && cp "/tmp/docker-app-plugin-${OSTYPE}" ~/.docker/cli-plugins/docker-app

Windows

Download the Windows tarball:

Invoke-WebRequest -Uri https://github.com/docker/app/releases/download/v0.8.0/docker-app-windows.tar.gz -OutFile docker-app.tar.gz -UseBasicParsing
tar xf "docker-app.tar.gz"

Install as a Docker CLI plugin:

New-Item -ItemType Directory -Path ~/.docker/cli-plugins -ErrorAction SilentlyContinue
cp docker-app-plugin-windows.exe ~/.docker/cli-plugins/docker-app.exe

Next steps

If you're interested in contributing to the project, jump to BUILDING.md and CONTRIBUTING.md.

Further examples are available in the examples directory.

app's People

Contributors

aiordache avatar carolinebriaud avatar chris-crone avatar dependabot-preview[bot] avatar ecwillis avatar eunomie avatar fuco1 avatar garethr avatar gesellix avatar glours avatar ijc avatar jcsirot avatar mat007 avatar mikeparker avatar mirake avatar mnottale avatar ndeloof avatar psftw avatar rumpl avatar shin- avatar silvin-lubecki avatar simonferquel avatar sspaink avatar stefanscherer avatar thajeztah avatar tullo avatar ulyssessouza avatar vdemeester avatar zappy-shu avatar zelahi 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  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

app's Issues

CI/CD Bootstrap

We're currently missing a CI/CD system and the bootstrapping around that.

Makefile doesn't work on Windows

The current Makefile contains a bunch of local undocumented assumptions which mean it doesn't run on Windows. eg.

  • assumption about availability of test
  • assumption about availability of grep
  • assumption about availability of tar

Some of the CI targets only require Docker, which might be one approach to a go default. Then allow an ENV to push things to run locally when required.

docker-app load with no arguments has incorrect error message

$ pwd
/src/github.com/docker/app/examples/hello-world
$ docker-app load
Error: error from docker save command: Error response from daemon: invalid reference format
: exit status 1
error from docker save command: Error response from daemon: invalid reference format
: exit status 1

Disabling a node in YAML should be explicit

Description

A YAML node can be disabled using a "enabled" key with a value:

version: "3.4"
services:
  monitor:
    enabled: "! ${myapp.debug}"

But the code handling this feature says that no value means disabling the node too:

version: "3.4"
services:
  monitor:
    enabled: # monitor is disabled

I suggest we should remove this implicit disable with no value, and error out, as I think that enabling should be explicit too.

⚠️ We should also add unit tests on this part!!

Incorrect exit code

When there's an error, we currently exit with code 0:

$ docker-app help --bad-flag
Error: unknown flag: --bad-flag
$ echo $?
0

Unpacking a loaded application fails

Regarding an application foo.docker-app

#
# Packing.
#
$ echo $PWD
xxx/foo.docker-app
$ docker-app save
$ docker image ls
foo.dockerapp                        latest              12d1cb28ad9f        44 seconds ago      5.79kB
[...] 
#
# Unpacking.
#
$ ls -l
$ docker-app load foo.dockerapp:latest
$ ls -l
-rw-r--r--  1 dimrok dimrok 13824 mai   22 15:27 foo.dockerapp
$ docker-app unpack foo.dockerapp
Error: mkdir foo.dockerapp: file exists

Renaming foo.dockerapp to whatever and then run docker-app unpack whatever works well.

Version

$ docker-app version
Version:      fb89420-dirty
Git commit:   fb89420
OS/Arch:      linux/amd64
Experimental: on
Renderers:    gotemplate

Wordpress example does not render

Description
The Wordpress example does not render.

Steps to reproduce the issue:

  1. cd examples/wordpress
  2. docker-app render wordpress.dockerapp

Describe the results you received:

Error: failed to load Compose file: volumes.db_data must be a mapping or null

Describe the results you expected:
The rendered Compose file.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker-app version:

Version:      v0.2.0-23-g913c753
Git commit:   913c753
Built:        Thu Jun 14 22:10:02 2018
OS/Arch:      darwin/amd64
Experimental: off
Renderers:    none

[Enhancement Request] Support rendering multiple apps

In Compose, we can specify multiple compose files by declaring the -f flag multiple times, so that we can combine multiple services together without having to define them into the same compose file:

docker-compose -f app1-compose.yml -f app2-compose.yml up -d

It would be useful to be able to render multiple apps into a single compose file, to support running multiple apps together from one docker-app render command line:

docker-app render app1.dockerapp app2.dockerapp | docker-compose -f - up -d

Render should follow the same rules as compose for declaring multiple compose files (overriding, etc).

docker.Makefile no longer works on Windows

A few unixisms have crept in which mean this no longer works on Windows. Specifically:

  • The BUILDTIME option relies on sed and time, which are likely not present. Best to either warn rather than error, or to replace with relevant Windows standard utilities
  • The addition of /dev/null to the git shell commands causes them to fail, as per the snippet below. Note this worked with the previous version.
make -f docker.Makefile cross
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
docker build --target= -t docker-app-cross --build-arg COMMIT= --build-arg TAG= --build-arg BUILDTIME= .

Visual Studio extension metadata are incomplete

The extension list can be accessed through Tools / Extensions and Updates….

The name and description are a bit rough, the icon could be customized eventually.
The information on the right generic, especially the Created by: Company label.

image

Some extensions have links to Release Notes, Getting Started, etc…

image

Network options get expanded incorrectly

Using the following Compsoe file

version: '3.5'
services:
  hello:
    image: hashicorp/http-echo:${version}
    command: ["-text", "${text}"]
    ports:
     - ${port}:5678
    networks:
     - backend

When this is rendered note the expansion of the list to include null.

version: "3.5"
services:
  hello:
    command:
    - -text
    - hello world
    image: hashicorp/http-echo:latest
    networks:
      backend: null
    ports:
    - mode: ingress
      target: 5678
      published: 8080
      protocol: tcp

CLI fails on command such as helm if the .dockerapp folder ends with a slash

Description

When running commands such as docker-app helm, bash completion puts a / at the end of the .dockerapp folder.

but docker-app fails if the name of the app ends with /.

Steps to reproduce the issue:

  1. cd to the examples folder
  2. start typing docker-app helm voting-app/voting
  3. trigger bash completion (docker-app helm voting-app/voting-app.dockerapp/)
  4. press Enter

Describe the results you received:

$ docker-app helm voting-app/voting-app.dockerapp/
Error: failed to read application metadata: open voting-app/voting-app.dockerapp/.dockerapp/metadata.yml: no such file or directory
$

Describe the results you expected:

$ docker-app helm voting-app/voting-app.dockerapp/
$

Output of docker-app version:

$ docker-app version
Version:      v0.2.0-53-gb7527d0
Git commit:   b7527d0
Built:        Thu Jun 28 14:15:57 2018
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Split file format should be more strict

The single-file / split-file format currently uses a fixed order for the files that are combined; this approach may not be future-proof / extensible for future enhancements (for example; multiple compose files, or multiple (named) configurations). (Just the file content of each section is likely insufficient to determine its contents, without attempting to fully parse each part, and trying to match it to a schema)

I suggest to either;

  • add meta-data to each section in the file (name of file, schema/file format used)
  • add a header-section that describes the content of each section/file included in the split-file
  • other options?

This is just a quick write-up to start the discussion, because I keep forgetting to bring this up, and it's important to decide on this before the project reaches GA

Dockerized makefile default target doesn't exist

make -f docker.Makefile
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
The system cannot find the path specified.
make: *** No rule to make target `bin', needed by `all'.  Stop.

Specifically the default target is set to bin test, but there is no top level bin target. Looks like cross might be the relevant target?

Use same time format as docker/cli for build time

$ docker-app version
Version:      0.1.0-155-g301048a
Git commit:   301048a
Build time:   2018-06-06T11:59:46.055462000+00:00
OS/Arch:      darwin/amd64
Experimental: off
Renderers:    none
$ docker version
Client:
 Version:      18.06.0-ce-dev
 API version:  1.37
 Go version:   go1.10.2
 Git commit:   7cbcdc0
 Built:        Tue May 29 14:48:59 2018
 OS/Arch:      darwin/amd64
 Experimental: true
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.06.0-ce-dev
  API version:  1.38 (minimum version 1.12)
  Go version:   go1.10.2
  Git commit:   7cbcdc0
  Built:        Tue May 29 14:56:29 2018
  OS/Arch:      linux/amd64
  Experimental: true

Generating Helm charts not dependent on the Compose Kubernetes controller

Description

Is there any possibility that docker-app will be able to generate Helm charts that are not dependent on the Compose Kubernetes controller available in Docker for Mac/Windows and Docker EE? Or, will the Helm support always rely on that?

Steps to reproduce the issue:

  1. Generate a Helm chart using docker-app helm.
  2. Attempt to install the chart outside of Docker for Mac/Windows or Docker EE.

Describe the results you received:

The resource version/type cannot be resolved.

Describe the results you expected:

The Helm chart is installed.

Additional information you deem important (e.g. issue happens only occasionally):

This limitation is noted in the README file.

Note that this requires the Compose Kubernetes controller available in Docker for Windows and Docker for Mac, and in Docker Enterprise Edition.

Output of docker version:

Client:
 Version:      18.05.0-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   f150324
 Built:        Wed May  9 22:12:05 2018
 OS/Arch:      darwin/amd64
 Experimental: true
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.05.0-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.10.1
  Git commit:   f150324
  Built:        Wed May  9 22:20:16 2018
  OS/Arch:      linux/amd64
  Experimental: true

Output of docker-app version:

Version:      v0.2.0
Git commit:   854872f
Build time:   2018-06-11T15:06:17.093522032+00:00
OS/Arch:      darwin/amd64
Experimental: off
Renderers:    none

Output of docker info:

Containers: 54
 Running: 22
 Paused: 0
 Stopped: 32
Images: 154
Server Version: 18.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
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: active
 NodeID: w97q3z0azzcv970g3e5hn9ski
 Is Manager: true
 ClusterID: o1cdcrn2etmq3kcz2aapse3n4
 Managers: 1
 Nodes: 1
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot Interval: 10000
  Number of Old Snapshots to Retain: 0
  Heartbeat Tick: 1
  Election Tick: 10
 Dispatcher:
  Heartbeat Period: 5 seconds
 CA Configuration:
  Expiry Duration: 3 months
  Force Rotate: 0
 Autolock Managers: false
 Root Rotation In Progress: false
 Node Address: 192.168.65.3
 Manager Addresses:
  192.168.65.3:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 773c489c9c1b21a6d78b5c538cd395416ec50f88
runc version: 4fc53a81fb7c994640722ac585fa9ca548971871
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.93-linuxkit-aufs
Operating System: Docker for Mac
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.786GiB
Name: linuxkit-025000000001
ID: OQ6Q:SF73:CGCW:XMZS:FHR4:BXKW:2EG3:KWGE:2EAK:OCTQ:2OWJ:LWCO
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 140
 Goroutines: 332
 System Time: 2018-06-19T21:01:05.7712531Z
 EventsListeners: 10
HTTP Proxy: gateway.docker.internal:3128
HTTPS Proxy: gateway.docker.internal:3129
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Add an extension to packed applications

Right now, docker-app pack / docker-app unpack work like a charm except the output file has no extension.

I'm personally not a huge of files without extensions (unless their name is self-explanatory, like Makefile).

Currently

docker-app pack -o my-app creates my-app.

Unpacking gives:

$ docker-app unpack my-app
$ ls -l
my-pack.docker-app/

Proposition

docker-app pack -o my-app creates my-app.docker-app-pack.

Unpacking gives:

$ docker-app unpack my-app.docker-app-pack
$ ls -l
my-app.docker-app

Version

$ docker-app version
Version:      fb89420-dirty
Git commit:   fb89420
OS/Arch:      linux/amd64
Experimental: on
Renderers:    gotemplate

docker-app helm fails helm lint.

Description
docker-app helm output isn't compliant with helm lint. The name of the chart of directory is expected to be the name of the chart.

Steps to reproduce the issue:

  1. docker-app helm
  2. helm lint

By default, `parameters.yml` contains `{}` if a compose file is used

PS: It's not the case if no compose-file is used.

How to reproduce

docker-app init -c cp.yml foo

Expected

cat foo.dockerapp/settings.yml 

Reality

cat foo.dockerapp/settings.yml 
{}

Version

Version:      0.1.0
Git commit:   9eec848
OS/Arch:      linux/amd64
Experimental: off
Renderers:

load / pull missing.

(experimental: off)

You can save and push but not load and pull.

How to reproduce

14:37 $ docker-app
Build and deploy Docker applications.

Usage:
  docker-app [command]

Available Commands:
  deploy      Deploy or update an application
  helm        Generate a Helm chart
  help        Help about any command
  init        Start building a Docker application
  inspect     Shows metadata and settings for a given application
  push        Push the application to a registry
  render      Render the Compose file for the application
  save        Save the application as an image to the docker daemon(in preparation for push)
  version     Print version information

Version

docker-app version
Version:      0.1.0-162-g9b311d2
Git commit:   9b311d2
Build time:   2018-06-07T12:36:50.253486313+00:00
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Add options to `init` to populate metadata.yml.

Currently

docker-app init scratch gives:

metadata.yml:

version: 0.1.0
name: scratch
description: ""
maintainers:
- name: root
  email: ""
targets:
  swarm: true
  kubernetes: true

Proposition: Add an option for every single entry.

docker-app init scratch --description "An app built from scratch" --maintainer "antony:[email protected]" --maintainer "dimrok:[email protected]" gives:

metadata.yml:

version: 0.1.0
name: scratch
description: "An app built from scratch"
maintainers:
- name: antony
  email: [email protected]
- name: dimrok
  email: [email protected]
targets:
  swarm: true
  kubernetes: true

Multi-platform file paths

For file paths we currently use path which description contains

The path package should only be used for paths separated by forward slashes, such as the paths in URLs. This package does not deal with Windows paths with drive letters or backslashes; to manipulate operating system paths, use the path/filepath package.

We should instead use path/filepath, for instance path.Join should be replaced with filepath.Join

Support helm for v1beta1 of Compose for Kubernetes

Description

Currently the created helm chart contains the v1beta2 stack struct which is not supported by EE 2.0. We should add the ability to write a helm chart in the v1beta1 format.

Steps to reproduce the issue:

  1. docker-app helm
  2. helm install ...

Describe the results you received:
When doing helm install against an EE 2.0 cluster, the chart fails to deploy because of a version mismatch.

docker-app render help is inconsistent

Usage says: [-s settings-file...] and flags say:

  -s, --set stringArray              Override settings values
  -f, --settings-files stringArray   Override settings files

Expected

[-s key=value...] [-f settings-file...] [flags]

Reality

[-e key=value...] [-s settings-file...] [flags]

How to reproduce

docker render --help
Usage:
  docker-app render <app-name> [-e key=value...] [-s settings-file...] [flags]

Flags:
  -h, --help                         help for render
  -s, --set stringArray              Override settings values
  -f, --settings-files stringArray   Override settings files

Version

Version:      fb89420
Git commit:   fb89420
OS/Arch:      linux/amd64
Experimental: off
Renderers:    gotemplate

Generate a self-documented metadata file

Having comments on each field would be nice.
This can be achieved by either:

  • (EPIC) adding a yaml_comment annotation and patching the marshaler to use it
  • Not using the marshaler to create the metadata.yml but a go template or something like that.

Support Compose file version 2 (for `runtime: nvidia`)

Description

It would be useful to support Compose file version 2. The use-case would be to use runtime: nvidia to access the local GPUs from docker-compose services containers.
(runtime option is not supported on Compose file version 3, see docker/compose#5360 (comment))

Steps to reproduce the issue:

  1. docker-compose.yaml with version: '2.4'
  2. docker-app init foo
  3. docker-app render

Describe the results you received:
Error: failed to load Compose file: unsupported Compose file version: 2.4

Describe the results you expected:
docker-app render works with Compose file version 2.

Output of docker-app version:

Version:      v0.2.0
Git commit:   854872f
Build time:   2018-06-11T15:06:17.093522032+00:00
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Using ports only works with Compose v3.2 and above

Given the following template

version: '3'
services:
  hello:
    image: hashicorp/http-echo:${version}
    command: ["-text", "${text}"]
    ports:
     - ${port}:5678

Rendering the template expands the ports definition:

$ docker-app-windows.exe render
version: "3.0"
services:
  hello:
    command:
    - -text
    - hello development
    image: hashicorp/http-echo:latest
    ports:
    - mode: ingress
      target: 5678
      published: 5678
      protocol: tcp

Passing this to Compose fails with the following error:

$ docker-app-windows.exe render | docker-compose -f - up
ERROR: The Compose file is invalid because:
services.hello.ports is invalid: Invalid port "{'mode': 'ingress', 'target': 5678, 'published': 5678, 'protocol': 'tcp'}", should be [[remote_ip:]remote_port[-remote_port]:]port[/protocol]
services.hello.ports contains an invalid type, it should be a string, or a number

The long syntax is only supported by Compose v3.2 and above (https://docs.docker.com/compose/compose-file/#short-syntax-1). Changing the version to 3.2 resolves this issue for this particular Compose file, but we want to make this work out of the box for past versions as well.

I think that we shouldn't expand this from how it was authored.

cobra's generated 'help' description is not capitalized.

Just a small detail but the generated help for <command_name>, unlike the other help messages, is not capitalized.

How to reproduce

$ docker-app init --help
[...]
Flags:
  -c, --compose-file string      Initial Compose file (optional)
  -d, --description string       Initial description (optional)
  -h, --help                     help for init
  -m, --maintainer stringArray   Maintainer (name:email) (optional)
  -s, --single-file              Create a single-file application

Version

$ docker-app version
Version:      0.1.0-162-g9b311d2
Git commit:   9b311d2
Build time:   2018-06-07T12:36:50.253486313+00:00
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Error message does not indicate which file is concerned

$ docker-app render wordpress/wordpress.dockerapp -f wordpress/with-secrets.yml 
Error: yaml: line 14: did not find expected key

The name of the key could be nice too.

Version

$ docker-app version
Version:      0.1.0-52-gb207ad0
Git commit:   b207ad0
OS/Arch:      linux/amd64
Experimental: off
Renderers:    

`docker render -f` doesn't overwrite settings.yml

Expected

docker-app render -f settings/development.yml
version: "3.6"
services: {}

Reality

docker-app render -f settings/development.yml
Error: open /home/dimrok/docker/apps/from-scratch.dockerapp/settings.yml: no such file or directory

How to reproduce

with:

tree
.
├── development
│   └── docker-compose.yml
├── docker-compose.yml
├── Makefile
├── metadata.yml
├── settings
│   └── development.yml
└── settings.yml
docker-app render -f settings/development.yml
version: "3.6"
services: {}
rm settings.yml 
docker-app render -f settings/development.yml
Error: open /home/dimrok/docker/apps/from-scratch.dockerapp/settings.yml: no such file or directory

Version

Version:      fb89420
Git commit:   fb89420
OS/Arch:      linux/amd64
Experimental: off
Renderers:    gotemplate

Generated compose-files are 3.2+ compatible

If you use a pre 3.2 compose-file (with ports or volumes) the resulting compose-file will be invalid.

Example:

$ cat compose-file.yml
version: "3.1"
services:
  hello:
    image: hashicorp/http-echo
    command: ["-text", "hello"]
    ports:
      - 5678:5678
$ docker-app init version -c docker-compose.yml 
$ cd version.dockerapp
$ docker-app render > foo.yml

Expected

$ docker stack deploy -c foo.yml app
Creating network app_default
Creating service app_hello

Reality

$ docker stack deploy -c foo.yml app
services.hello.ports.0 must be a string or number

Proposition

We should write a warning and update the version the version of the generated compose-file to 3.6 (or 3.2, the minimum).

Version

$ docker-app version
Version:      fb89420
Git commit:   fb89420
OS/Arch:      linux/amd64
Experimental: off
Renderers:    gotemplate

Help shows twice (docker-app init)

Help message show twice.

How to reproduce

$ docker-app init 
Error: "docker-app init" requires exactly 1 argument.
See 'docker-app init --help'.

Usage:  docker-app init <app-name> [-c <compose-file>] [-d <description>] [-m name:email ...] [flags]

Start building a Docker application
"docker-app init" requires exactly 1 argument.
See 'docker-app init --help'.

Usage:  docker-app init <app-name> [-c <compose-file>] [-d <description>] [-m name:email ...] [flags]

Start building a Docker application

Version

$ docker-app version
Version:      0.1.0-162-g9b311d2
Git commit:   9b311d2
Build time:   2018-06-07T12:36:50.253486313+00:00
OS/Arch:      linux/amd64
Experimental: off
Renderers:    none

Download link in readme is broken

Description

The download link : https://github.com/docker/app/releases/download/v0.1.0/docker-app-linux.tar.gz refers to the old release and is broken

Steps to reproduce the issue:

  1. Refer to installation section

Describe the results you received:

wget https://github.com/docker/app/releases/download/0.1.0/docker-app-linux.tar.gz
--2018-06-18 09:24:32--  https://github.com/docker/app/releases/download/0.1.0/docker-app-linux.tar.gz
Resolving github.com (github.com)... 192.30.253.112, 192.30.253.113
Connecting to github.com (github.com)|192.30.253.112|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2018-06-18 09:24:32 ERROR 404: Not Found.

Describe the results you expected:
Download the release binary

[app-name] in docker-app push is not optional.

$ ls -l
-rw-r--r-- 1 dimrok dimrok 1786 mai   22 14:26 docker-compose.yml
-rw-r--r-- 1 dimrok dimrok  167 mai   22 10:42 metadata.yml
-rw-r--r-- 1 dimrok dimrok  437 mai   22 14:27 settings.yml
$ docker-app push -p dimrok/ -t latest
Error: error from docker push command: invalid reference format
: exit status 1
$ cd ..
$ ls -l
drwxr-xr-x 5 dimrok dimrok 4096 mai   22 15:58 voting-app.dockerapp
$ docker-app push -p dimrok/ -t latest
Error: error from docker push command: invalid reference format
: exit status 1
$ docker-app push -p dimrok/ -t latest voting-app.dockerapp
✔

Correct wordpress example helm chart name

Description

The wordpress example shows a helm chart folder ending in .helm. This should be .chart.

Steps to reproduce the issue:

  1. docker-app helm wordpress
  2. ls

Describe the results you received:
Example does not match real output:

$ ls
README.md           prod-settings.yml   with-secrets.yml    wordpress.chart     wordpress.dockerapp

Describe the results you expected:
Example should match above result.

Output of docker-app version:

Version:      v0.2.0-31-g85ea7e0-dirty
Git commit:   85ea7e0
Built:        Wed Jun 20 14:42:45 2018
OS/Arch:      darwin/amd64
Experimental: off
Renderers:    none

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.