Planning and Analysis
This section will guide you through the planning and analysis steps that you should follow before performing an off-host deployment of Posit Connect.
These steps include:
- Analysis of existing content requirements (for migrations)
- Identification of performance critical content (for migrations)
- Network connectivity verification
- Shared storage capacity verification
- Posit Connect license validation (for migrations)
- Planning for downtime (for migrations)
Analysis of existing content
If your Connect installation is new, you can skip this step.
The information gathered as part of this step will be of use to you post-deployment.
Content Requirements
Connect uses images with Quarto to prepare and execute your content. These images must satisfy the existing R & Python content requirements as well as any system dependencies required for the content’s dependent packages or libraries.
Exact Quarto requirements are content dependant. For more information, see the table in the Building Docker Images for use as Execution Environments section. If you are migrating from an existing Connect server, make sure the same version of Quarto is now available in your content images.
If you are unsure which version of Quarto is running on your existing server, you can use this endpoint using the Connect API to find out.
The Server API Cookbook contains the recipe Content Runtimes - R and Python versions in use to assist you in understanding the needs of your existing content.
Posit has made a set of public Docker images available, which are used by the Helm Chart by default. We recommend performing your initial migration using these default images and then after confirming the default images are functional, proceed to configuring your custom images.
Identification of performance-critical and important content
During the post-deployment validation of your new Connect server, you have the opportunity to optimize first-time access of content previously deployed to your old server. You can also validate that any particularly important content items are executing successfully on your new server. These post-deployment validation steps require a list of relevant content GUIDs and access paths, which you should identify and record for later.
If you cannot easily identify important content items, the rsconnect content search
tool included in the rsconnect-python
package can perform usage analysis. This tool provides content query functionality which can be used to help identify important content items.
For further details on optimizing first-time content access, see the Server Management Runtime Cache Workflow.
Pull the Helm charts used in this guide
# Posit Connect
helm repo add rstudio https://helm.rstudio.com
# Pull the latest versions of the Helm charts
helm repo update
Network connectivity verification
If you don’t have PostgreSQL or shared storage installations yet, don’t worry. We will create them in the next section.
Verify that the Kubernetes cluster has connectivity to shared storage. If migrating, also confirm connectivity to the shared storage where the Connect data files are located.
Verify that you can access the PostgreSQL server from within the cluster.
Verify that the ports required for accessing the Connect server are not blocked (by default,
30000
-32767
is the range expected).
Posit Connect license validation
If your Connect installation is new, you can skip this step.
If you plan to use an existing Connect license, you also need to confirm that you have enough license activations available. Check your license status using the steps outlined in the Licensing Management guide. Reach out to your Posit Customer Success representative before proceeding.
To request a separate evaluation license, you can email your Customer Success Representative or sales@posit.co and specify that you are trialing this feature.
Planning for downtime
If your Connect installation is new, you can skip this step.
Coordinate with your stakeholders and warn users ahead of an upgrade with system messages. Your Connect server will be out-of-service during the migration.
The time required depends on the following factors:
- Number of content bundles published to your server
- The difference of GID / UID assignments between your existing files vs what is present on the runtime images
- The amount of content migration optimization that you choose to perform
Once your planning is done, you can continue on to the Kubernetes Cluster Preparation steps.