Skip to main content

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

  • 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

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 promptly

  • 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

  • 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 the 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 that will never be released

  • Use staging to make configuring cleanup easier

  • Staging Concepts

Storage

Use blob stores to manage attached storage

  • Blob stores are a location to store your artifacts, use them to attach additional storage or separate specific environments.

  • These tasks are required for each blob store you create and will need to be configured and regularly run to clean up your repository.

    • Admin - Cleanup unused asset blobs

    • Admin - Compact blob store

    • Repair - Reconcile component database from blob store

  • Additional information

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 blob store

  • 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

  • Learn about the Logging options

  • Use the nexus and request logs to track activity

  • Details about each log file in the Directories documentation

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