如何使用公共和私有映像创建docker-compose.yml文件？

Question

I'm trying to create a docker-compose.yml file for a specific team of developers at work. I've pushed our private images up to a private registry (Azure Container Registry) and that's ok/working :)

Next I'm trying to test out how to get the dev's of this particular team to run the docker-compose file which will pull down all the images and then start them all.

I've figured out that the developers will need to do this:

-> docker login -u <admin username of my registry> <domain of the registry>
-> docker-compose pull

This pulls down my private images (from ACR the private registry), but not any images in docker hub (the public registry).

• Q1: Is it possible to mix and match?
• Q2: Is there another way to make a 'user' which is only READONLY. I've read some stuff about service accounts or something but it's really confusing and I have no idea if how to do that/if that's the right way.

Here's a snippet my sample docker-compose file, which contains both public and private images. Do note how I'm trying to fully qualify the image domains...

version: '3.5'

services:

ravendb.data:
  image: hub.docker.com/ravendb/ravendb
  expose: 
    - "8080"
  networks:
    - backend
  container_name: ravendb.data
  labels:
    - "traefik.enable=false"

accounts.api:
  image: <snip>.azurecr.io/<snip>/<snip>
  networks:
<rest all snipped>

Answer 1

Q1 - Two issues, somewhat related -

1. Your Docker Hub registry FQDN is wrong in the RavenDB image directive - hub.docker.com is the human readable website, the public Docker registry resides at registry.hub.docker.com or index.docker.io (append v1 to those uri's to get the API).

2. You don't need the full public registry FQDN to pull from the public registry - its the default, and docker commands will by default pull from there if they don't detect a FQDN in the image tag preceding the image name.

Q2 - I'm not sure how Azure Container Registry works, but I'd be astonished if you can't create a readonly user. The normal registry is a REST based API server, and can be controlled either by setting its permissions internally or by putting a reverse proxy in-front of it with the POST/PUT/DELETE and PATCH verbs requiring a different authed user to the GET verb.