Deploy Docker image of acapy cloudagent python

[abhimin]

Hi, My requirement is to deploy the aries-cloudagent:py36-1.16-1_0.7.4 image in openshift. For this I have created a wrapper image and trying to deploy without docker compose in openshift. But condition is like only one port in the openshift used to expose the app.As per documentation acapy agent docker container require two ports to expose .so my requirement is to expose the container using one port and make acapy run without using docker compose. Please suggest for the acapy cloud agent container setup and cloud deployment. Also openshift using python version 3.8 while image version is 3.6 due to this getting ssl version compatibility issue and pods getting crashed.

[swcurran]

We've got lots of ACA-Py instances deployed to OpenShift so it's definitely possible. @WadeBarnes has built up a lot of scripts to manage this over time. I think the scripts themselves are specific to how our OpenShift environment is setup -- with Dev/Test/Prod workspaces for each deployment.

This folder contains the generic OpenShift settings for all the deployments -- e.g. the YAML file is probably useful. Then, we have tools that read, generate and use environment variables to override the specific settings for each deployment (Dev/Test/Prod for each ACA-Py deployment). You can look around the repo for the set of ACA-Py agents configured and deployed from the repo.

Hope that helps.

[Balamurugan-G]

@swcurran Per our company policy, we are allowed to use only https which would connect to a target port in container. We'll be able to connect to only one application port though the application listens on 2 ports. So do we have any option to run the agent in only one port through which we can handle the requests to AGENT_ADMIN_PORT and AGENT_HTTP_PORT?

[WadeBarnes]

@Balamurugan-G, We have a similar restriction. The example @swcurran pointed you to only has it's public interface exposed. With that configuration it's assumed the agent's controller would be accessing the admin interface internally to the namespace. An example of an agent configuration with both public and admin interfaces exposed can be found here. In this case separate routes (URLs) are used to direct traffic to the two different application ports.

[Balamurugan-G]

Hi @WadeBarnes, Thanks a lot for the response. The restriction in our organisation is we are allowed to expose only one container port (with existing templates). Per below service definition, two ports have been exposed which is not possible using our available templates. Could you tell me the possible solution to use this agent in our environment?

• kind: Service apiVersion: v1 metadata: name: ${PREFIX}${NAME} labels: name: ${PREFIX}${NAME} app: ${APP_NAME} app.kubernetes.io/part-of: ${APP_NAME} app-group: ${APP_GROUP} role: ${PREFIX}${ROLE} env: ${TAG_NAME} spec: ports:
  • name: ${NAME}-admin port: ${{AGENT_ADMIN_PORT}} protocol: TCP targetPort: ${{AGENT_ADMIN_PORT}}
  • name: ${NAME}-http port: ${{AGENT_HTTP_PORT}} protocol: TCP targetPort: ${{AGENT_HTTP_PORT}} selector: name: ${PREFIX}${NAME}

[Balamurugan-G]

@WadeBarnes, Also could you tell me how can we start the agent with ssl_context?

[abhimin]

Deployed successfully