A storage server supplies persistent file storage to an application. In a microservices design, a dedicated video-storage service hides the underlying provider behind a REST API, allowing the video-streaming service to retrieve videos without depending on a particular storage technology. section 4.4.3 section 4.4.6
Treat the storage server as an independent application capability:
- Store files in external cloud storage while keeping storage details inside the video-storage microservice. section 4.4.6
- Connect the video-streaming service to the storage service rather than loading videos directly from its filesystem. section 4.4.3
- Configure the service with storage-account credentials and connect containers through Docker Compose. section 4.4.3
- Preserve a replaceable interface so the application can switch providers with minimal disruption. section 4.4.6
Video storage behind a service boundary
An application uses Azure Storage for its videos. The azure-storage microservice exposes the storage capability, while Docker Compose names its container video-storage and lets video-streaming retrieve videos through that service. The streaming service therefore remains unaware of the provider’s identity. section 4.4.3
Listing 4.4 Adding a new microservice to our Docker Compose file
version: '3'
services:
azure-storage: #1
image: azure-storage #2
build:
context: ./azure-storage
dockerfile: Dockerfile
container_name: video-storage #3
ports:
- "4000:80"
environment:
- PORT=80
- STORAGE_ACCOUNT_NAME=${STORAGE_ACCOUNT_NAME} #4
- STORAGE_ACCESS_KEY=${STORAGE_ACCESS_KEY} #4
restart: "no"
video-streaming:
image: video-streaming
build:
context: ./video-streaming
dockerfile: Dockerfile
container_name: video-streaming
ports:
- "4001:80"
environment:
- PORT=80
↓ #5
- VIDEO_STORAGE_HOST=video-storage #6
- VIDEO_STORAGE_PORT=80 #6
restart: "no"
Use the Compose listing to inspect the storage service’s image, build context, container name, port, credentials, and connection settings. section 4.4.3
