koyeb compose

[pawelbeza]

docker-compose alike functionality for koyeb

[brmzkw]

Few notes:

• For CreateAppIfNotExists, it could be nice to have the same logic as here
• For the CLIError, make sure to always add a Solution
• How could the type KoyebCompose contain archives?
• As of today, CreateApp only contains a Name. What if it contained more? the type KoyebCompose doesn't seem future proof, but idk what's the best option

On a docker-compose file, you have to define a volume and reference them in the services section:

services:
  backend:
    image: example/database
    volumes:
      - db-data:/etc/data

  backup:
    image: backup-service
    volumes:
      - db-data:/var/lib/backup/data

volumes:
  db-data:

I see several alternatives to the one in the PR for the compose file.

For example:

apps:
  myapp:
  myapp2:

services:
  - app: myapp
     name: myservice
     ports: ["80:80"]

  - app: myapp2
     name: myservice2
     ports: ["80:80"]

And to reference archives:

apps:
  myapp:
  myapp2:

archives:
  my-flask-app:
    build: .

services:
  - app: myapp
     name: myservice
     ports: ["80:80"]
     archive: my-flask-app

  - app: myapp2
     name: myservice2
     ports: ["80:80"]

(note that several services could use the same archive)

Alternatively, since apps don't have any other parameter except their names, we could have the following syntax:

services:
  - name: myapp/myservice
     ports: ["80:80"]

  - name: myapp2/myservice2
     ports: ["80:80"]

Or, even better:

services:
  myapp/myservice:
     ports: ["80:80"]

  myapp2/myservice2:
     ports: ["80:80"]

And in the future, if we want to add parameters to the app, we can simply add the section which is optional by default:

apps:
  myapp:
    futureparam: xxx

services:
  myapp/myservice:
     ports: ["80:80"]

  myapp2/myservice2:
     ports: ["80:80"]

here myapp has futureparam set, but not myapp2 which has the default values

---

Also, there's something I don't understand. In the example of the command, you show what the compose file looks like:

		# Init koyeb-compose.yaml file
		$> echo 'apps:
		  - name: example-app
		    services:
				- name: example-service1
				  image: nginx:latest
				  ports:
				  	- 80:80
				- name: example-service2
				  path: github.com/koyeb/golang-example-app
				  branch: main
				  ports:
				  	- 8080:8080
				  depends_on:
				  	- example-service1' > koyeb-compose.yaml
		# Apply compose file
		$> koyeb compose koyeb-compose.yaml

But:

type KoyebComposeService struct {
	koyeb.DeploymentDefinition `yaml:",inline"`
	DependsOn                  []string `json:"depends_on"`
}

the type contains a DeploymentDefinition. I'm not sure to understand how it works for path, branch and image to be top level keys when I think they should be subkeys of docker or git. Is it an issue in the documentation, or in my understanding?