Updating Containers
You can use synchronization features within Planeo to update the containers in your stacks when files are changed locally, either by automatically rebuilding docker images, or if docker builds take too long, you can directly push files to your containers. To use this feature, edit a stack and click on the "Sync" tab, and add any local directories you want to sync.
Keep in mind that changes won't be applied to stacks until you click "Update" and also that file changes won't be synced to the stack until relevant local files are changed.
Rebuilding Images
In order to rebuild an image we need several pieces of information
The context path (we use the local path being synced)
The Dockerfile as a relative path to the local path
The image name so we know how to tag the built image
Whether to push the image or not
To configure this, click on the docker whale icon, fill in the information, and click "Sync". Be sure to click "Update" to apply your changes. Refer to Pushing Images and Updating Stacks before you apply your changes, and ensure the Dockerfile path provided is relative to the contect directory associated with this sync.
Now, from the edit stack view, when you make changes you should see your sync status change to "Syncing" and back to "Synced once the image is built. You should also be able to see the image in your local docker environment.
Pushing Images
By selecting "Push" from the Push column, you can have your image pushed to a remote registry based on the image name, i.e. docker push {image}:{tag}. This requires that you have access to push to that registry via your local docker environment and you must be logged in from within your terminal, if not the sync will error.
Updating Stacks
Keeping images rebuilt can save you time in the future by maintaining a docker image layer cache for expensive operations, however the primary use case is to use the generated image to keep your stack updated. To do this you'll need to link to stack arguments that allow you to alter the image name and tag in your helm chart for this image. You can set these parameters by clicking on the link icon under "Actions".
From this view you can pick specific stack arguments to override with the generated image details. These need to be arguments configured in the stack, and exposed via the template. When these are set, whenever a new image is built, your stack will be updated with new stack argument values referencing the newly built image, and your stack will be automatically deployed.
Keep in mind that you can add multiple image rebuild syncs for multiple images in your helm chart, each referencing distinct arguments which will allow you to keep several images within your stack updated at the same time.
Troubleshooting
Any errors related to building or pushing images should show up on the command line, common issues with this are
The cluster the stack is being deployed to does not have access to pull the image from the repo
The context path or Dockerfile within that path are not correct
The local docker build environment does not have access to push to the remote registry
Images are being rebuilt, but not pushed, and the cluster is running on a different docker instance and does not have access to the built image
Syncing Files
To sync files between a local folder and a remote folder in your stack we need to know
The local and remote folders
The specific resource and container you want to sync files to
Any optional command to run after a sync is complete to apply changes
Click on the folder icon to fill this information out and click Sync. Be sure to click Update to apply your changes.
We use the generated resources from your template and their container names to populate the list of resources (deployments, daemonsets and statefulsets). Keep in mind that if the values driving the helm template change such that the set of resources and containers are changed, then this value could become incorrect, and you may need to re-edit this form to correct it.
Reloading with Changes
The post sync command is useful if you need to trigger a reload of a running service, or you need to recompile some source code in your container. If this process becomes too complicated, it may be worth just relying on the image rebuild functionality, but be sure to wrap post sync command functionality in scripts for consistency and reuse. Simply define a short and lightweight command to execute in each pod once file changes have been synced. If this command fails, it will show up as part of the sync status.
Syncing to Multiple Pods
By adding additional syncs you can update files the same local folder to distinct sets of resources within your stack. Planeo will sync file changes (creates, updates, deletes and renames) to all pods within the resource, however keep in mind that it will sync changes, so as pods are created/deleted their state may be inconsistent. This does mean that you can keep all pods of all deployments within your stack up to date with file changes, even if you are syncing them to distinct remote paths, and they should become eventually consistent.
Using Both File and Image Sync
You can configure both file and image syncs for a local path, however, to avoid duplicating work and inconsistent state, the image rebuild sync will be pre-empted by the file sync, even if there is no overlap between the resources being synced to by both methods. You can avoid this by setting up multiple distinct local folders to sync from, or just using one form of sync. This behaviour is likely to change in the future.
File/image sync walkthough
For an overview of how to use file/image sync, watch this video
Last updated