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
- Limit requests to external repositories to only the artifacts that are needed from that proxy
- Reduce exposure to public ecosystems
- Prevent dependency namespace confusion attacks
- Speed up read access on group repositories by reducing the external calls through the proxies
- Additional information:
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
- Docker Subdomain Connectors are far more performant than 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
- Blob stores are a location to store your artifacts
- Use them to attach additional storage or separate out specific environments
- Expect performance issues creating a large number of blob stores
- These tasks are configured by blob store
- Additional information
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
- Learn about the logging options
- Use the nexus and request logs to track activity
- Details about each log file
Scripting
Use the inbuilt swagger-ui to test the REST API
- find it inside the UI under Administration -> System -> API
- Submit API requests to ideas.sonatype.com
- REST API documentation
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
A detailed article covering this change is here: Scripting Nexus Repository Manager 3.