(proposal) Transitioning from Mixins to Custom Remote Invocation Images

[jmcudd]

What design is being proposed?

The proposal suggests transitioning Porter's architecture from utilizing mixins to adopting custom invocation images that can be referenced remotely. The primary motivation for this design is to eliminate the complexities of creating a custom mixin and shift towards using custom invocation images. This encourages community-driven contributions, supports a broader range of languages and technologies, and aligns with Docker's universally accepted standards.

Additionally, invocation images will automatically mount the porter.yaml file, reducing or eliminating the need for manual "wiring" of porter.yaml metadata, streamlining the process for developers.

Publicly available invocation images, much like the mixin CLI, would be indexed and searchable, creating a vibrant ecosystem of pre-built images for various devops stacks such as Kubernetes, Helm, Terraform, etc.

Additional Context

The proposed transition will chiefly impact areas such as the CLI, porter.yaml manifests, and the way bundles are defined and managed. This change allows for more flexible use of remote invocation images within the porter.yaml, enabling reuse and promoting community-created standard images.

The existing custom Dockerfile functionality can serve as a precursor to new custom invocation images. Developers can refine custom Dockerfiles into invocation images, which can then be shared through community platforms or repositories, enhancing collaboration and tool accessibility.

Risks/Concerns

• Transition Complexity: There may be challenges for users transitioning to this new model, necessitating well-documented migration strategies and extensive user support.
• Security and Integrity: Introducing remote invocation images requires careful management to ensure the authenticity and integrity of images used. Strict validation, security layers, and possibly image signing will be critical defenses.
• Development Workload: Increased demands on development and maintenance are expected to support the transition, requiring additional resources for systematic upgrades and tool creation.

What other approaches were considered?

Alternative approaches included maintaining a hybrid model to offer legacy support for mixins. This would reduce disruption but involve maintaining dual models, potentially complicating the overall system architecture. Another approach was enhancing existing mixins to make them easier to use, but this was seen as an insufficient measure given the greater flexibility and community engagement custom invocation images offer.

Implementation Details

Upon acceptance, the proposal would make changes centered around the porter.yaml file, allowing direct specification of custom remote invocation images. This encourages the development and uptake of community-driven solution images. Below is an example configuration to illustrate this concept:

name: my-porter-bundle
version: 1.0.0
description: Example managing infrastructure and Kubernetes invocation images.
invocationImages:
  - name: terraform-tools
    image: ghcr.io/myorg/terraform-invocation-image:latest
  - name: helm-tools
    image: ghcr.io/myorg/helm-invocation-image:stable

install:
  - description: "Install Infrastructure resources"
    invoke:
      - name: terraform-tools
      - action:
          run: terraform apply -auto-approve
  - description: "Deploy application to Kubernetes"
    invoke:
      - name: helm-tools
      - action:
          run: helm install myapp ./myapp-chart

Additional Examples

Example 1: Kubernetes Deployment Workflow

name: k8s-deployment-bundle
version: 1.0.0
description: A bundle handling the deployment, upgrade, and removal of a Kubernetes application.

invocationImages:
  - name: kubernetes-tools
    image: ghcr.io/devteam/k8s-invocation-image:latest

install:
  - description: "Deploy application to Kubernetes cluster"
    invoke:
      - name: kubernetes-tools
      - action:
          run: kubectl apply -f app-deployment.yaml

upgrade:
  - description: "Update Kubernetes deployment configuration"
    invoke:
      - name: kubernetes-tools
      - action:
          run: kubectl set image deployment/app app=app:v2

uninstall:
  - description: "Remove application from Kubernetes cluster"
    invoke:
      - name: kubernetes-tools
      - action:
          run: kubectl delete -f app-deployment.yaml

Example 2: Infrastructure Management with Terraform

name: infra-management-bundle
version: 1.1.0
description: A bundle that manages infrastructure using Terraform for provisioning, updating, and teardown.

invocationImages:
  - name: terraform-tools
    image: ghcr.io/infra/terraform-invocation-image:latest

install:
  - description: "Provision infrastructure"
    invoke:
      - name: terraform-tools
      - action:
          run: terraform init && terraform apply -auto-approve

upgrade:
  - description: "Apply Terraform updates to infrastructure"
    invoke:
      - name: terraform-tools
      - action:
          run: terraform apply -auto-approve

uninstall:
  - description: "Destroy infrastructure"
    invoke:
      - name: terraform-tools
      - action:
          run: terraform destroy -auto-approve

Example 3: CI/CD Pipeline with Docker

name: cicd-bundle
version: 2.0.0
description: A CI/CD bundle that sets up, updates, and clews up a Docker-based application.

invocationImages:
  - name: docker-tools
    image: ghcr.io/container/docker-invocation-image:stable

install:
  - description: "Build and run Docker container for initial deployment"
    invoke:
      - name: docker-tools
      - action:
          run: |
            docker run -d -p 80:80 --name myapp-container ${bundle.images.myapp.repository}@${bundle.images.myapp.digest}

upgrade:
  - description: "Upgrade the Docker container to a new version"
    invoke:
      - name: docker-tools
      - action:
          run: |
            docker stop myapp-container
            docker rm myapp-container
            docker run -d -p 80:80 --name myapp-container ${bundle.images.myapp.repository}@${bundle.images.myapp.digest}

uninstall:
  - description: "Stop and remove the Docker container"
    invoke:
      - name: docker-tools
      - action:
          run: |
            docker stop myapp-container
            docker rm myapp-container

Checklist

• [x] An announcement of this proposal has been sent to the Porter mailing list: https://porter.sh/mailing-list
• [ ] This proposal has remained open for at least one week, allowing time for community feedback.

[kichristensen]

Hi @jmcudd, this is an interesting proposal. There exist a similar PEP 005, and the initial proposal for the PEP can be found here. The PEP was never completed, but I think it is worth taking some of the same considerations into account.