Deploy a packaged application
Use an OCI image that contains the application and its dependencies. An explicit image version gives your team a recognizable release artifact to deploy and investigate.
Runtime / Containers
Bring the image. Keep your release process.
Deploy services from compatible OCI images on Podman. Configure environment variables and ports, follow lifecycle actions and inspect service logs.
- Image
- registry.example.com/team/api:1.0
- Runtime
- Podman / compatible OCI image
- Configuration
- Application environment variables
- Networking
- Application port + service access
- Persistence
- Check the selected storage options
Illustrative image reference. Supply an accessible image for your application.
- Deployment input
- Compatible OCI image
- Administration
- Image, configuration and service logs
- Best fit
- Application APIs and background workers
Application architecture / Containers
Make the release artifact the starting point.
Package each API or worker in a versioned image. Supply its environment, ports and dependency connections at deployment. Review storage options before persisting application data.
What this gives you
A clear relationship between the image you build and the service your team operates.
Where it fits
What you can do with containers.
For APIs, web services and workers already packaged as container images.
Configure the service boundary
Supply required environment variables and exposed ports through the available configuration fields. Define how the process reaches databases, queues and other services you operate.
Follow startup and lifecycle
Inspect the deployed container state and use available lifecycle actions from the console. Application startup, network reachability and persistent data each need their own check.
Read application logs
Use the available log view to investigate startup errors and request handling. Maintain the image, dependencies and log content as part of your application release process.
In practice
One image. A clearly defined service.
Choose a container when your software is already packaged as an OCI image and its configuration can be supplied at deployment.
An application API
Package the API and its dependencies in an image. Configure the listening port and the connections to its backing services.
Plan for
Image architecture, environment variables and endpoint access.
A background worker
Run a compatible worker image that connects to the queue or application service you operate.
Plan for
Outbound access, retry behavior and orderly shutdown.
A release evaluation
Run a versioned image with separate test configuration to review an application change.
Plan for
Image version, test data and persistent storage behavior.
The workflow
From configuration to a running workload.
- 01
Select a workload
Choose a published container offer and a compatible image.
- 02
Configure the runtime
Set the supported environment and network options for your application.
- 03
Inspect the service
Follow logs, check connectivity and adjust your application configuration.
Configuration checks
Prepare the operating environment.
- Confirm that the runtime can access a compatible image.
- Document required variables, listening ports and external dependencies.
- Check how application data survives restarts and image changes.
Responsibilities
Know what you maintain.
Containers / Questions
A few details before you start.
Can I use an existing application image?
Start with an OCI image compatible with the selected runtime and its architecture. Check registry access and supported configuration fields before ordering.
Where should my application keep data?
Review the persistence options of the chosen offer. Treat files inside a container as application state that needs an explicit storage and recovery plan.
Who updates the application dependencies?
Your team maintains and rebuilds the image, selects the version to deploy and checks the result. Keep a known working version and a rollback procedure.
Connected products