Post-Deployment

This section will guide you through the post-deployment steps for your off-host installation of Posit Connect.

Note

If you encounter any errors while accessing content on your new server for the first time, your first resolution step should be to initiate a rebuild of the content item. The technique to initiate a rebuild differs depending on the type of content and can range from a simple page reload to a toolbar button available within the Posit Connect dashboard.

Optimizing access for pre-existing content

Note

If your Connect installation is new, you can skip this step.

As long as your new Connect server continues to use the same database and the StorageClass set for the Connect data directory is backed by a PersistentVolume containing your existing Connect data directory; all source-level content bundles previously deployed to your old server are available to the new server. However, to properly present the content, the new server needs to restore the runtime environment required by the content (referred to as rebuilding the content). Rebuilding is performed automatically upon the first-time access of a piece of content. When this happens, users can experience sub-optimal performance as dependent packages are downloaded and installed.

To avoid this, it is recommended that important content be rebuilt ahead of first-user access. Connect provides tooling which allows an administrator or publisher to initiate a rebuild without requiring direct access to the content.

Using the list of content that you prepared during the Identification of performance critical and important content step, you can use the rsconnect content build tool to rebuild the content.

Custom content container image preparation

Most organizations exercise control over the Docker images used for content execution rather than simply using the public images which Posit makes available.

If this is applicable to your installation, see the Content Image Appendix for more information.

Implement High Availability

With the Helm Chart values.yaml file created earlier, the deployment of Connect was configured with one replica so that traffic for a single connection is always routed to the same Connect pod.

To implement multiple replicas of the Connect pod, you need to update the replicas count in your values.yaml file and then run helm upgrade. For example, the following change would enable three running replicas:

# Controls how many instances of Connect are created.
replicas: 3

When enabling High Availability for Connect, an Ingress Controller with Sticky Sessions enabled is required. This configuration is described in the Enabling External Access Appendix.

Review temporary deployment configuration

Earlier, when describing the deployment process, we recommended several configuration modifications which should be reverted now that deployment is complete.

Remember to review your configuration and revert any deployment-specific changes.