# Administration Best Practices ## Access Control ### Avoid using the default Anonymous Role in production - By default, the [Anonymous Role](https://help.sonatype.com/en/anonymous-access.html "Anonymous Access") 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](https://help.sonatype.com/en/default-role.html "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 - 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: - [Repository Routing Helps Protect Against Dependency Hijacking Attacks](https://blog.sonatype.com/new-feature-repository-routing) - [Namespace Confusion: Minimizing Risk with Nexus Repository](https://blog.sonatype.com/namespace-confusion-minimizing-risk-with-nexus-repository) - [How to Control Nexus Groups with Effective Routing Rules](https://blog.sonatype.com/2010/01/how-to-control-nexus-groups-with-effective-routing-rules/) - [Routing rules configuration](https://help.sonatype.com/en/routing-rules.html "Routing Rules") ### 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 - [Docker Subdomain Connectors](https://help.sonatype.com/en/docker-subdomain-connector.html "Docker Subdomain Connector") are far more performant than 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: - [Staging Concepts](https://help.sonatype.com/en/staging-concepts.html "Staging Concepts") - [Cleanup Policies](https://help.sonatype.com/en/cleanup-policies.html "Cleanup Policies") ### 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](https://help.sonatype.com/en/staging-concepts.html "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](https://help.sonatype.com/en/tasks.html "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 - [Storage Planning](https://help.sonatype.com/en/storage-planning.html "Storage Planning") - [Blob Store Configuration](https://help.sonatype.com/en/blob-stores.html "Blob Stores") - [Blob Store API](https://help.sonatype.com/en/blob-store-api.html "Blob Store API") ### 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](https://help.sonatype.com/en/blob-stores.html#promoting-a-blob-store-to-a-group "Promoting a Blob Store to a 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](https://help.sonatype.com/en/status-api.html "Status API") for the real-time status of the server - Consider using the [Prometheus](https://help.sonatype.com/en/prometheus.html "Prometheus") endpoint as a data source for other tools like [Grafana](https://grafana.com/docs/grafana/latest/features/datasources/prometheus/) or [Elastic](https://www.elastic.co/what-is/prometheus-monitoring) ### Keep the audit log enabled - The [audit log](https://help.sonatype.com/en/auditing.html "Auditing") 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](https://help.sonatype.com/en/logging.html "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 - Find it inside the UI under Settings -> System -> API - Submit API requests to [ideas.sonatype.com](http://ideas.sonatype.com/) - [REST API documentation](https://help.sonatype.com/en/automation.html "Automation") ### 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: [Nexus Repository](https://support.sonatype.com/hc/en-us/articles/360045220393) ## Search results No results found