February 12, 2024 — River Point Technology (RPT), announced today that CRN®, a brand of The Channel Company, has named RPT to its Managed Service Provider (MSP) 500 list in the Elite 150 category for 2024.


The MSP 500 list compiled by CRN serves as a comprehensive guide to identifying and recognizing the top Managed Service Providers (MSPs) in North America. MSPs play a crucial role in supporting businesses by offering managed services that enhance efficiency, simplify IT solutions, and optimize return on investment.

The annual MSP 500 list is divided into three sections: the MSP Pioneer 250, recognizing companies with business models weighted toward managed services and largely focused on the SMB market; the MSP Elite 150, recognizing large, data center-focused MSPs with a strong mix of on- and off-premises services; and the Managed Security 100, recognizing MSPs focused primarily on off-premises and cloud-based security services.

The MSP 500 list aims to showcase and celebrate MSPs that are driving growth and innovation in the industry. These service providers not only enable businesses to harness complex technologies but also contribute to maintaining a strong focus on core business goals without stretching financial resources. By categorizing MSPs based on their business models and areas of expertise, the list helps end-users find the right partners to meet their specific needs and challenges in the rapidly evolving technology landscape.

River Point Technology is a recognized leader in cloud and DevOps services, supporting Fortune 500 companies in accelerating digital transformation and pushing boundaries. Our dedicated team of engineers and architects makes deploying, integrating, and managing new technology easier by providing cutting-edge custom solutions. We also help organizations achieve ongoing success and maximize the value of their technology investments through top-notch enablement programs.

Jennifer Follett, VP of US Content and executive Editor CRN, T he Channel Company, emphasized the significance of managed services for businesses at various scales, stating, “Managed services provide a route for businesses of all sizes to maintain efficiency and adaptability throughout their growth journey. The solution providers featured in our 2024 MSP 500 list are introducing cutting-edge managed services portfolios to the market, enabling their clients to achieve success by optimizing their IT budgets. This allows businesses to allocate resources strategically, concentrating on mission-critical tasks that drive future success.”

“Our core value is driving successful outcomes for our customers, so it is satisfying to see this being acknowledged by our inclusion on the CRN MSP500 list as an Elite 150 partner. I am incredibly proud of our team for their dedication and commitment to being the best in their craft which allows us to bring this value to our customers. We will continue to innovate and humanize technology by leveraging our Value Creation Technology process.” said RPT’s owner and CEO Jeff Eiben.

The MSP 500 list will be featured in the February 2024 issue of CRN and online at www.crn.com/msp500.

About River Point Technology

River Point Technology (RPT) is an award-winning cloud and DevOps service provider that helps Fortune 500 companies accelerate digital transformation and redefine what is possible. Our passionate team of engineers and architects simplify the deployment, integration, and management of emerging technology by delivering state-of-the-art custom solutions. We further position organizations to experience Day 2 success at scale and realize the value of their technology investments by offering best-in-class enablement opportunities. These include the subscription-based RPT Resident Accelerator program that’s designed to help enterprises manage the day-to-day operations of an advanced tech stack, the just-launched RPT Connect App, and our expert-led training classes. Founded in 2011, our unique approach to evaluating and adopting emerging technology is based on our proprietary and proven Value Creation Technology process that empowers IT teams to boldly take strategic risks that result in measurable business impact. What’s your vision? Contact River Point Technology today and see what’s possible.

About The Channel Company

The Channel Company enables breakthrough IT channel performance with our dominant media, engaging events, expert consulting and education, and innovative marketing services and platforms. As the channel catalyst, we connect and empower technology suppliers, solution providers and end users. Backed by more than 40 years of unequalled channel experience, we draw from our deep knowledge to envision innovative new solutions for ever-evolving challenges in the technology marketplace. www.thechannelco.com

Follow The Channel Company: Twitter, LinkedIn, and Facebook.

© 2024 The Channel Company LLC. CRN is a registered trademark of The Channel Company, LLC. All rights reserved.

The Channel Company Contact:

Kristin DaSilva

The Channel Company

[email protected]

curl -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/vnd.api+json" \
 --request POST \
  -d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions" <<EOT
​
{
  "data": {
    "type": "registry-provider-versions",
    "attributes": {
      "version": "${VERSION}",
      "key-id": "${KEY_ID}",
      "protocols": ["6.0"]
    }
  }
}
EOT 

Overview

HashiCorp’s Terraform Cloud provides a centralized platform for managing infrastructure as code. It’s a leading provider in remote Terraform management with remote state management, automated VCS integrations, and integrations. One of its features, a private registry, can be used to develop internal Terraform providers where control, security, and customizations are paramount. An organization will want to deploy a private provider if a public is disqualified for direct upstream consumption for a specific reason. Some more specific use cases include: ​

  1. Customization and Control: A private registry allows organizations to maintain control over their proprietary or custom-built Terraform providers. It enables them to manage, version, and distribute these providers securely within the organization.
  2. Security and Compliance: A private registry ensures that only authorized users within the organization can access and utilize specific Terraform providers for sensitive or proprietary infrastructure configurations. This control aids in compliance with internal policies and regulatory requirements.
  3. Versioning and Stability: With a private registry, teams can maintain a stable versioning system for their Terraform providers. This helps ensure project infrastructure configurations remain consistent and compatible with the specified provider versions. ​ Let’s explore an example using the Terraform Provider Scaffolding Framework to build a custom Terraform provider and publish it to a private registry. Scaffold provides a framework starter kit that you can use out of the box to replace your APIs. ​

Signing Your Provider

​ Code signing guarantees that the generated artifacts originate from your source, allowing users to verify this authenticity by comparing the produced signature with your publicly available signing key. It will require you to generate a key pair through the GNU PGP utility. To develop, you can use the following command. Ensure you replace GPG_PASSWORD and your name with values that make sense.

gpg --default-new-key-algo rsa4096 --batch --passphrase "${GPG_PASSWORD}" --quick-gen-key 'Your Name <[email protected]>' default default

Export Public Key

​ With your newly generated key securely stored, the next step involves exporting and uploading it to Terraform Cloud. This action facilitates verification while deploying your signed artifacts, ensuring their authenticity within the platform’s environment. The GPG Key API requires the public key to validate the signature. To access the list of key IDs, you can execute: gpg --list-secret-keys --keyid-format LONG. The key is denoted in the output.

[keyboxd]
---------
sec   rsa4096/<KEY ID> 2023-11-22 [SC] [expires: 2026-11-21]

​ You can then get your public key as a single string. KEY=$(gpg --armor --export ${KEY_ID} | awk '{printf "%s\\n", $0}'). You’ll then need to build a payload with the output of that file and POST that to https://app.terraform.io/api/registry/private/v2/gpg-keys. The ORG_NAME is your Terraform cloud organization.

{
  "data": {
        "type": "gpg-keys",
        "attributes": {
            "namespace": "${ORG_NAME}",
            "ascii-armor": "${KEY}"
        }  
    }
}

Export Private Key For CI (Optional)

​ If you plan to use this key in a CI Platform, you can also export the key and upload it gpg --export-secret-keys --armor ${KEY_ID} > /tmp/gpg.pgp to a secure Vault. ​

Packaging Terraform Providers with GoReleaser

Goreleaser simplifies the process of building and releasing Go binaries. Using GoReleaser, we can bundle different architectures, operating systems, etc.

  1. Create a terraform registry manifest. The protocol version is essential. If using Plugin Framework, you want 6.0. If using Plugin SDKv2, you’ll wish to 5.0.
{
    "version": 1,
    "metadata": {
      "protocol_versions": ["6.0"]
    }
}

​ 2. Configuring Goreleaser Ensure your goreleaser.yml configuration includes settings for multi-architecture support and signing. This file should live at the provider’s root, next to your main codebase. ​

before:
  hooks:
    - go mod tidy
builds:
- env:
    - CGO_ENABLED=0
  mod_timestamp: '{{ .CommitTimestamp }}'
  flags:
    - -trimpath
  ldflags:
    - '-s -w -X main.version={{ .Version }} -X main.commit={{ .Commit }}'
  goos:
    - freebsd
    - windows
    - linux
    - darwin
  goarch:
    - amd64
    - '386'
    - arm
    - arm64
  ignore:
    - goos: darwin
      goarch: '386'
  binary: '{{ .ProjectName }}_v{{ .Version }}'
archives:
- format: zip
  name_template: '{{ .ProjectName }}_{{ .Version }}_{{ .Os }}_{{ .Arch }}'
checksum:
  extra_files:
    - glob: 'terraform-registry-manifest.json'
      name_template: '{{ .ProjectName }}_{{ .Version }}_manifest.json'
  name_template: '{{ .ProjectName }}_{{ .Version }}_SHA256SUMS'
  algorithm: sha256
signs:
  - artifacts: checksum
    args:
      - "--batch"
      - "--local-user"
      - "{{ .Env.GPG_FINGERPRINT }}"
      - "--output"
      - "${signature}"
      - "--detach-sign"
      - "${artifact}"
    stdin: '{{ .Env.GPG_PASSWORD }}'
release:
  extra_files:
    - glob: 'terraform-registry-manifest.json'
      name_template: '{{ .ProjectName }}_{{ .Version }}_manifest.json'
changelog:
  skip: true
  1. Tag your branch Your git strategy may differ, but GoReleaser uses branch tags to determine versions.
git tag 0.0.1
git checkout 0.0.1

​ 4. Execute GoReleaser to bundle the binaries locally without publishing. We skipped publishing as we will manually upload them to Terraform Cloud.

export GPG_TTY=$(tty)
export GPG_FINGERPRINT=${KEY_ID}
goreleaser release --skip=publish

Go Releaser ​ Now we have our artifacts.

Publishing to Terraform Cloud Private Registry

Release Process ​ ​ Once you have the signed binaries, you can publish them to the Terraform Cloud private registry. Hashicorp provides a guide, which we will follow.

Register the provider (first time only)

  1. Create a provider config file and POST that body utilizing your terraform cloud API token. A provider name is usually a singular descriptor representing a business unit, such as google or aws.
curl --header "Authorization: Bearer ${TERRAFORM_CLOUD_API_TOKEN}" \
--header "Content-Type: application/vnd.api+json" \
--request POST \
-d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers" <<EOT
​
{
 "data": {
     "type": "registry-providers",
     "attributes": {
         "name": "${PROVIDER_NAME}",
         "namespace": "${ORG_NAME}",
         "registry-name": "private"
     }
 }
}
EOT

Uploading your versions

  1. Create Version Shell within Private Registry Providers
curl -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/vnd.api+json" \
 --request POST \
  -d @- \
"https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions" <<EOT
​
{
  "data": {
    "type": "registry-provider-versions",
    "attributes": {
      "version": "${VERSION}",
      "key-id": "${KEY_ID}",
      "protocols": ["6.0"]
    }
  }
}
EOT 

The response will contain upload links that you will use to upload the SHA256SUMS and SHA256.sig files.

"links": {
    "shasums-upload": "https://archivist.terraform.io/v1/object/dmF1b64hd73ghd63",
    "shasums-sig-upload": "https://archivist.terraform.io/v1/object/dmF1b37dj37dh33d"
 }
  1. Upload Signatures
# Replace ${VERSION} and ${PROVIDER_NAME} with actual values
curl -sS -T "dist/terraform-provider-${PROVIDER_NAME}_${VERSION}_SHA256SUMS" "${SHASUM_UPLOAD}"
curl -sS -T "dist/terraform-provider-${PROVIDER_NAME}_${VERSION}_SHA256SUMS.sig" "${SHASUM_SIG_UPLOAD}"
  1. Register platform for every arch and operating system.
FILENAME="terraform-provider-${PROVIDER_NAME}_${VERSION}_${OS}_${ARCH}.zip"
SHA=$(shasum -a 256 "dist/${FILENAME}" | awk '{print $1}' )
# OS ex. darwin/linux/windows
# ARCH ex. arm/amd64
# FILENAME. terraform-provider-<PROVIDER_NAME>_<VERSION>_<OS>_<ARCH>.zip. Define through name_template
​
curl -H "Authorization: Bearer ${TOKEN}" \
 -H "Content-Type: application/vnd.api+json" \
 --request POST \
 -d @- \
  "https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions/${VERSION}/platforms" << EOT
  {
    "data": {
        "type": "registry-provider-version-platforms",
        "attributes": {
            "shasum": "${SHA}",
            "os": "${OS}",
            "arch": "${ARCH}",
            "filename": "${FILENAME}"
        }
    }
}
EOT

The response will contain upload the provider binary to:

"links": {
  "provider-binary-upload": "https://archivist.terraform.io/v1/object/dmF1b45c367djh45nj78"
}
  1. Upload archvied binaries
curl -sS -T "dist/${FILENAME}" "${PROVIDER_BINARY_URL}"
  1. Repeat steps 3 and 4 for every architecture and operating system.

Using the provider

​ ​ Registry ​ ​ ​ Private providers hosted within terraform cloud are only available to users within the organization. When developing locally, ensure you set up credentials through the terraform login, creating a credentials.tfrc.json file.

credentials "app.terraform.io" { 
  # valid user API token: 
  token = "xxxxxx.atlasv1.zzzzzzzzzzzzz"
}

With the authentication bits setup, you can utilize the new provider by defining the provider block substituting in those existing variables.

terraform {
  required_providers {
    ${PROVIDER_NAME} = {
      source = "app.terraform.io/${ORG_NAME}/${PROVIDER_NAME}"
      version = "${VERSION}"
    }
  }
}
​
provider "${PROVIDER_NAME}" { 
  # Configuration options 
}

Document Provider

For user consumption, a common practice is to provide provider documentation for your resources utilizing Terraform plugin docs. This plugin generator allows you to generate markdowns from examples and schema definitions, which users can then consume. At the time of publication, this feature is currently not supported within the terraform cloud. ​

Cleanup

​ To remove the provider from the registry.

Delete version

curl -H "Authorization: Bearer ${TOKEN}" \
 --request DELETE \
  "https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}/versions/${VERSION}"

Delete provider

curl -H "Authorization: Bearer ${TOKEN}" \
 --request DELETE \
  "https://app.terraform.io/api/v2/organizations/${ORG_NAME}/registry-providers/private/${ORG_NAME}/${PROVIDER_NAME}"

Deregister GPG Key

curl -H "Authorization: Bearer ${TOKEN}" \
 --request DELETE \
https://app.terraform.io/api/registry/private/v2/gpg-keys/${ORG_NAME}/${KEY_ID}

Conclusion

​ Publishing custom Terraform providers to the Terraform Cloud private registry involves bundling, signing, and uploading binaries and metadata through the API. Following these steps, you can effectively manage and distribute your Terraform provider to support various architectures and operating systems. ​

https://app.terraform.io/api/registry/private/v2/gpg-keys/${ORG_NAME}/${KEY_ID}

By Dan Quackenbush

 

In the dynamic world of tech conferences, there exists a gem unlike any other – KubeCon, where the orchestrators of Kubernetes gather to share tales of triumph and innovation. As a seasoned navigator of cluster administration, I found myself immersed in the heartbeat of this dynamic symphony of ideas, particularly drawn to the stories that unfolded after the initial deployment – the fascinating Day 2 Operations. 

The first stop, Major League Baseball + Argo CD: A Home Run, implemented GitOps through Argo CD to empower feature-driven development using Helm charts. The stage was set with a compelling case study, highlighting how developers were handed the reins to their applications without drowning in the sea of YAML configurations. Through the power of abstraction, Helm deployed through Argo, allows them to focus on features, such as enabling monitoring, injecting secrets, and exposing their services across two hundred clusters, bringing consistency to the service runtime landscape. 

Next up was a talk on the alpha feature introduced in Kubernetes 1.27 – In-Place Resource Resize. A meaningful change for administrators dealing with dynamic resource-intensive applications, especially those built on JVM. Sustainable Scaling of Kubernetes Workloads with In-Place Pod Resize and Predictive AI, unfolded the power of dynamically adjusting pod sizes, unveiling a new level of flexibility for Kubernetes clusters. It was not about vertical scaling; but talked about how we could use ML to power these configurations without over-allocating resources. 

 

The talk FinOps at Grafana Labs illuminated the path to financial accountability, transforming it into a cultural cornerstone. The speaker painted a vivid picture of a world where accountability, transparency, and a culture of openness were the guiding lights. Through real-world examples, the audience learned the impact of “cash positive chaos testing,” moving to spot instances, aligning cost optimization measured against service reliability, and the importance of continuously stress-testing applications in various infrastructure conditions. 

 

In a creative twist, Burden to Bliss: Eliminate Patching and Upgrading Toil with Cluster Autoscaler at Scale, dived into leveraging Cluster Autoscaler for applying security patches. The ingenious strategy involved creating new node pools and strategically shifting pods with tolerations to the patched nodes. By creating new node pools with the patched system and strategically forcing a single pod with toleration to the patched node, the talk demonstrated how eventual consistency mechanisms could be leveraged to shift all pods to the new node through eviction. This innovative strategy ensures that security patches are seamlessly applied without affecting ongoing workloads. 

 

The final act in this symphony of talks explored the intersection of Kubernetes, service mesh, and content delivery networks (CDNs). Take It to the Edge: Creating a Globally Distributed Ingress with Istio & K8gb, unveiled the critical role of service mesh in handling disruptions during DNS load balancing, offering a solution to the dreaded 502 errors. Through health checks and local failover endpoints, the talk unfolded how Kubernetes Global Balancer could redefine CDN construction, providing a resilient and scalable solution for distributed applications. 

 

It is always interesting to hear how people are handling similar problems. These talks show us, how as a Kubernetes administrator, with a new mindset, can provide a central way for developers to be feature vs configuration driven, scale those workloads either in place, or through cheaper means, all while reducing the burden on sustainability. Once deployed, these applications can then spread across regions, on hardened nodes. I invite you to check out the talks, dive into the dynamic Day 2 Operations, and discover the secrets shared by industry leaders.