Question: What workflows do developers want from Rancher Desktop?

[agracey]

After the 1.0 release, we will move into adding more features to Rancher Desktop. It would be helpful to us to know how people are using our tools!

For anyone working with containers as a developer, what workflows do you use?

If you can, please let us know:

• How are you using containers
• What your workflow is
• If you use standalone containers, Kubernetes, or both

Thank you for helping us make Rancher Desktop a better experience for everyone!

[atoy3731]

I'm not sure of feasibility, but when I'm developing a new Docker image, I still generally use docker-compose for quick-and-dirty inter-networked, multi-container testing. For instance, if my image requires a Postgres image, it's way simpler to test locally with docker-compose as opposed to all of the necessary K8s manifests (deployments, services, ingress, etc.)

For instance:

version: '3'
services:
  postgres:
    image: postgres
    container_name: postgres
    hostname: postgres
    environment:
      POSTGRES_DB: test
      POSTGRES_PASSWORD: password
      POSTGRES_USER: admin

  test-app:
    image: test-app:1.0
    container_name: test-app
    hostname: test-app
    ports:
      - "8080:80"
    environment:
      DB_HOST: postgres
      DB_PORT: 5432
      DB_NAME: test
      DB_USER: admin
      DB_PASS: password

[agracey]

That makes a lot of sense and we have had a few conversations about adding in compose.

Is it mostly just databases or do your compose files tend to more complex?

The reason I'm asking is that another other features that we've been exploring is having a "marketplace" of services to deploy and I'm wondering if that would solve your issue in a different way. (Either way, we will still continue looking at compose and I'll let one of the engineers comment on feasibility!)

[agracey]

Also, thank you for your feedback! It helps a lot.

[atoy3731]

Is it mostly just databases or do your compose files tend to more complex?

I'd say it depends on what I'm working on. For simplicity's sake, I'd say in most cases it'd be a UI/reverse-proxy container, backend/API container, and DB/indexer/storage container (with only the UI truly requiring host-level port forwarding).

[mgingell]

I have a similar workflow and use nerdctl compose as an alternative to docker-compose. It works for me for most of my use cases. So I alias docker-compose to 'nerdctl compose --project-directory $(pwd)'. Once I get this orchestration working, I work on the k8s yaml resource files.
When building and debugging images with docker when running into issues, I would often run the image that was cached at the point the build broke. Something like 'docker run --rm -it 1ba4ef /bin/sh' I then work inside the container until I figure out the problem, fix the Dockerfile, and carry on. Not sure I can do that using rancher-desktop/k8s buildkit via 'nerdctl build'.
I also use k9s and Lens to help me figure out what is going on in the cluster.

[dougbreaux]

For me, Rancher Desktop is the alternative/replacement for Docker Desktop, where my use case is just simple single-container local execution, sometimes as testing before pushing images for our k8s (OpenShift) platform to run, and sometimes to run specific apps locally that I need to use.

So, running without k8s would be nice for me, as #985 requests, but not essential.

For me, making Windows internal networking as seamless as possible, including docker localhost, is my biggest ask. e.g. #893

Followed by any other Windows niceties, like GUI for running containers, viewing logs, mounts, etc.

[agracey]

Followed by any other Windows niceties, like GUI for running containers, viewing logs, mounts, etc.

We are looking at pulling the Rancher cluster management UI in as an optional feature, that would get your access to logs, shell, and many other things for workloads in k8s. One of the things that we are trying to figure out currently is what's needed if we build something similar for workloads running on the "standalone container" side. It's a definite need so stay tuned!

Regarding networking, that's a hard problem (especially since we need to solve it for windows, mac, and linux) but we are looking at ways to make it easier for us to match our users' expectations.

[markbaumgarten]

Here's my general workflow from idea/proof of concept to deployment.

I prefer using my linux dev machine for most things together with docker-compose.

1. Get my proof of concept working...docker build...docker run...
2. Move all docker stuff into docker-compose.yml. Define all env variables in an .env file and refer to this in all services.
3. Then docker-compose build/push
4. Use kompose convert -c -f projectname.yml
5. kompose package projectname
6. curl -u xxxx --data-binary "@projectname-0.0.1.tgz" https://xxxxx/api/charts

From here it is very simple to deploy on either Windows(Rancher Desktop) OR in a real test/production cluster using helm.

Using rancher desktop makes it easier to get end users to try out software locally without being dependent on access to a publicly available cluster.