Hello there!
Today Qovery lets you deploy any external resources with IAC frameworks like Terraform, Cloudformation, Serverless etc… via the Lifecycle job service type (more info here)
We are working on simplifying this flow, trying to provide a smooth but flexible experience to manage most of the edge cases.
The idea in a few words
We will provide a default configuration to run your IAC scripts. We will still use the lifecycle job in the background but we will provide you with a few default values for Dockerfile, actions and resources. You will still be able to customize the default behaviour in the settings once the service is created.
More in details…
Let’s take this example: deploy an RDS database with Cloudformation
Note: The approach is pretty much the same with other IAC tools like Terraform, serverless etc…
Creation flow
We will ask you 3 things:
- the repository containing the Cloudformation template
- the input required by your Cloudformation template (parameters). We won’t support by default to pass parameters one by one, you will have to store all of them in a single file.
- some environment variables necessary to execute the Cloudformation template (AWS creds, region, name of the template to execute)
You can find here a prototype of the creation flow
In the background, Qovery will instantiate for you a Lifecycle job with a default value for:
- Dockerfile (stored on the Qovery control plane).
FROM alpine:3.20.0
RUN <<EOF
set -e
apk update
apk add dumb-init
apk add ‘aws-cli>2.16’ --repository=Index of /alpine/edge/community/
apk add jq
adduser -D app
mkdir /data
chown -R app:app /data
EOF
WORKDIR /data
USER app
RUN cat < entrypoint.sh
#!/bin/sh
if [ “$JOB_INPUT” != ‘’ ]
then
PARAMETERS=“file://$JOB_INPUT”
fi
CMD=$1; shift
set -ex
cd cloudformation
STACK_NAME=“qovery-stack-${QOVERY_JOB_ID%%-*}”
case “$CMD” in
start)
echo ‘start command invoked’
aws cloudformation deploy --stack-name $STACK_NAME --template $CF_TEMPLATE_NAME --parameter-overrides $PARAMETERS
echo ‘generating stack output - injecting it as Qovery environment variable for downstream usage’
aws cloudformation describe-stacks --stack-name $STACK_NAME --output json --query ““Stacks[0].Outputs”” > /data/output.json
jq ‘. | { (.OutputKey): { “value”: .OutputValue, “type” : “string”, “sensitive”: false } }’ /data/output.json > /qovery-output/qovery-output.json
;;
stop)
echo ‘stop command invoked’
exit 0
;;
delete)
echo ‘delete command invoked’
aws cloudformation delete-stack --stack-name $STACK_NAME
aws cloudformation wait stack-delete-complete --stack-name $STACK_NAME
;;
raw)
echo ‘raw command invoked’
aws cloudformation “$1” “$2” “$3” “$4” “$5” “$6” “$7” “$8” “$9”
;;
debug)
echo ‘debug command invoked. sleeping for 9999999sec’
echo ‘Use remote shell to connect and execute commands’
sleep 9999999999
exit 1
;;
*)
echo “Command not handled by entrypoint.sh: ‘$CMD’”
exit 1
;;
esac
EOF
COPY --chown=app:app . cloudformation
RUN <<EOF
set -e
chmod +x entrypoint.sh
cd cloudformation
EOF
ENV CF_TEMPLATE_NAME=must-be-set-as-env-var
ENV AWS_REGION = must-be-set-as-env-var
ENV AWS_SECRET_ACCESS_KEY = must-be-set-as-env-var
ENV AWS_ACCESS_KEY_ID = must-be-set-as-env-var
ENTRYPOINT [“/usr/bin/dumb-init”, “-v”, “–”, “/data/entrypoint.sh”]
CMD [“start”]
- Actions (which Cloudformation run at Start/stop/delete of the environment)
- Resources (CPU/RAM necessary to run your cloudformation job)
Settings
You will find the same settings you have in the existing Lifecycle Job but you will also see a Dockerfile section where you will be able to modify the Dockerfile that was automatically assigned by Qovery.
Need your feedback
What do you think about this new flow?
Do you think we have missed anything?
Feel free to comment or contact me if you want to discuss more about it!