Post-Deployment
This section will guide you through the post-deployment steps for your off-host installation of Posit Connect.
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
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.
You adjusted your R package repository URLs to install from package sources. Switch back to using a repository URL that provides package binaries.
You applied the recommended temporary configuration changes. Revert to the values used before your changes or remove those settings to use the default values.
Remember to review your configuration and revert any deployment-specific changes.