Administration Best Practices

Access Control

Avoid using the default Anonymous Role in production

  • By default, the Anonymous Role gives read access to all repositories and cannot be edited
  • We recommend disabling anonymous access for production instances
  • When required, anonymous access should be assigned a custom role to control the allowed repositories

Configure the Default Role for global permissions

  • Default Role is automatically granted to all authenticated users
  • At a minimum, assign the same privileges as the Anonymous Role

Avoid complicated content selectors when possible

  • Content Selectors are best used when designating write access to a namespace for a development team
  • Use for partitioning a shared/mono repository
  • Use for namespace enforcement on team repositories

Design your repository architecture in terms of granting access rather than restricting it

  • Negative/exclusionary content selectors are not performant and are easy to override with other liberal permissions.
  • Use team-specific repositories when restricting read access.

Component Repositories 

Review proxy repository concepts

Have your build-servers use a group repository as their component registry

  • Group repositories give you better control of the components available to your builds
  • You will not have to later modify your build environment to manage the used repositories
  • Group repositories are the key to maturing into a staging environment

Avoid many remote proxy repositories in a single group

  • External requests are made for each remote proxy in the group
  • Having a high number of remote proxies will increase latency for every request

Use HTTPS for remote proxies to protect against man-in-the-middle attacks

  • Audit your proxies to make sure you are not using HTTP endpoints.

Use routing rules on all of your external proxy repositories 

Use a hosted maven repository for storing any files where you want clear namespacing

  • Maven repositories don't limit the types of files which can be stored in the repository
  • They have better support for enforcing namespaces over raw repositories when organizing your files

Use a single repository for development over creating a repository for each team

  • Creating a repository for each team will lead to repository sprawl
  • Many hundreds of repositories will increase management costs and lower performance
  • Use Content Selectors to create namespaces for each team
  • Use a new repository to lock down access to private artifacts

Content Replication

Use content replication to prefetch artifacts for remote teams

  • Deploy components to a centrally hosted repository using proxies to distribute to remote teams
  • Very effective for large binaries which may lead to latency and timeouts during remote builds

Content Replication is not a disaster recovery solution

  • Configuration and metadata are not replicated so recovery using content replication will be inconsistent
  • Content replication is managed through the remote server so there is no way for the central server to ensure transmission

Use content replication to better scale with proxy nodes

  • The scaling with proxies model is far more effective with content replication
  • The read-only nodes will already contain the content before it is requested

Avoid complicated mesh-like configurations for replication between multiple instances

  • Bi-directional replication can become complicated when replicating to more than one node
  • Consider using a central hub and spoke model to centralize all of your artifacts
  • Deploy to the central hub when possible 

Monitor replication log files for performance and consistency

  • Use the logging to determine if all the content is being replicated in a timely manner
  • Adjust the timing of the scheduled task for content that is not immediately requested


Formats

Use specific maven groups for different policy types (RELEASE or SNAPSHOT) 

  • Avoid having a single MIXED policy repo housing both release and snapshot artifacts.

Use Nuget v.3 instead of v.2

  • version 3 is much more performant than version 2

Use Docker Subdomain Connectors over connector ports

Push images to a Docker group repository

  • Pro users can push images directly to a group repository
  • On the group, you select a Writable Repository in the configuration menu


Cleanup

Control costs by cleaning up unused components from your repositories

  • Improves system performance
  • Reduces the need for additional system resources
  • Reduce the risk of running out of space
  • Helps developers find what they need faster
  • Reduce backup costs
  • Removes vulnerable components from the repository

  • Additional Information:

Configure cleanup policies on all repositories where you are actively adding components

  • Repositories can quickly grow if you are not removing as many components as you are adding
  • Review static imported repositories bi-annually to determine if the artifacts should be retained

Balance what you are removing to match as much as you are adding to a repository

  • Use component age (in the repository) to remove components roughly as fast as they are added
  • Use last download dates to only keep what is actively being used.
  • Determine the optimal "last download" as a bit longer than how frequently you build your applications

Use cleanup to remove components that are no longer being used in your proxies

  • Only retain the proxied components that are currently being used
  • Cleanup artifacts that have not been downloaded in the last 30 days
  • This is the most effective way to remove vulnerable components

Cleanup development artifacts faster than production

  • A modern DevOps workflow can lead to a high number of regular builds
  • Be aggressive when cleaning up builds which will never be released
  • Use staging to make configuring cleanup easier
  • Staging Concepts

Storage

Avoid creating many blob stores

Avoid creating a blobstore per repo or every team

  • This pattern does not scale with larger instances and will cause performance issues
  • Each blob store has its own set of maintenance tasks which are manually configured

Use blob store groups for fast-growing repositories

  • Large artifacts in your hosted repositories may quickly use up your available space
  • A blob store group is an easy way to add additional storage with any change to your repositories
  • Blob store groups support mixed storage types to blend faster disks with slower object storage

Keep staging environments in the same blob store

  • Staging moves artifacts from one repository to another
  • The staging move action is a fast metadata update when components are in the same blob store
  • Components will need to be copied when the staging repos are on different blob stores 

Set a quota on your blobstore

  • Configure notifications when specific quota points are reached
  • Regularly monitor your storage usage to avoid running out of space
  • Test your notification configuration

Monitoring

Use external tools to monitor the health of your repository

  • Monitoring and reporting are expensive operations that can negatively affect your repository
  • Offload reporting to external tools to minimize the impact on production servers
  • Use these endpoints for the real-time status of the server
  • Consider using the Prometheus endpoint as a data source for other tools like Grafana or Elastic.

Keep the audit log enabled

  • The audit log is to track configuration changes
  • This log is useful when troubleshooting/investigating issues

Use a test environment for running reports

  • Use a recent backup to avoid putting strain on your production environment

Mine the log files to learn how your repository is being used

Scripting

Use the inbuilt swagger-ui to test the REST API

Avoid using the REST API when existing functionality would do a better job

  • Cleanup policies are a scalable way to remove components than using the delete component API
  • Native build tools do a better job at dependency resolution than searching the repository

 Avoid testing scripts in production

  • Use a backup of the server in a testing environment

Avoid using the groovy scripting engine

  • The scripting engine is not fully documented and will eventually be deprecated
  • Scripts can cause performance issues and damage the server
  • Scripts depend on unpublished internal objects which will change and break your code
  • Use the REST API for all supported development