Deploying Nexus Repository on Orange Pi with Ansible: A Comprehensive Guide

Introduction

Artifact repositories play a crucial role in modern software development and DevOps practices. They provide a central place to store and manage all the binary outputs of your build process, including packages, containers, installers, and more. This allows development teams to share and consume these artifacts in a reliable, repeatable way as they flow through the CI/CD pipeline and ultimately to production environments.

Nexus Repository OSS is one of the most popular artifact repository solutions. It‘s fully open source, supports a wide range of formats, and can scale up to handle extremely large workloads. While commonly deployed on x86 infrastructure, Nexus can also run on ARM-based systems like the Orange Pi single board computer.

In this guide, we‘ll walk through deploying Nexus onto an Orange Pi using Ansible for configuration management. We‘ll cover everything from initial provisioning through advanced customization and integration into your development workflow. By the end, you‘ll have a production-ready artifact repository that can grow with your needs.

Why Run Nexus on Orange Pi?

At first glance, it may seem odd to run Nexus on a small ARM SBC rather than a beefy x86 server. However, there are several advantages to this approach:

• Cost: An Orange Pi board costs a tiny fraction of a full server, making it ideal for home labs, test environments, or cost-sensitive production use cases. Electricity and cooling costs are also far lower.

• Size and Noise: The Orange Pi is about the size of a deck of cards and is completely silent. This allows deploying your artifact repository in space-constrained environments without disruption.

• Performance: For small to medium size workloads, a quad-core 2 GHz ARM CPU and 4 GB of RAM is more than enough to run Nexus. Many teams will be surprised by how much capacity they can squeeze out of these tiny devices.

Of course, there are tradeoffs. You wouldn‘t want to deploy a high-volume, mission-critical artifact repository on an SBC. And you may need to do more tuning and optimization to handle heavy concurrent traffic compared to running on x86.

Sizing Your Deployment

Before deploying Nexus, it‘s important to size your Orange Pi device based on your expected load. Here are some key considerations:

• Storage: Nexus stores all artifacts on the filesystem. So you‘ll need enough disk space to hold all your packages, containers, and other binaries. A good starting point is 16 GB for the OS and Nexus app, plus the total size of your artifacts plus 20% buffer. So if you expect to store 50 GB of packages, provision at least a 64 GB SD card or SSD.

• Memory: Nexus runs on the Java VM and benefits greatly from having lots of RAM. 4 GB is the minimum recommended, but 8 GB will provide much better performance if you have a high number of concurrent clients.

• CPU: Nexus can make full use of multi-core CPUs. For best performance, choose a quad-core or higher SBC. Note that Nexus will automatically detect and use all available cores with no tuning needed.

• Network: If you have a large number of clients pulling artifacts concurrently, 100 Mbps Ethernet may become a bottleneck. Consider gigabit Ethernet or deploying multiple nodes if you need more network throughput.

Here are some stats from Sonatype (the makers of Nexus) on how Nexus performs on different hardware:

Cores	Memory	Max Throughput	Avg Throughput
4	8 GB	2.3 Gbps	300 Mbps
8	16 GB	5.6 Gbps	900 Mbps
16	32 GB	11.2 Gbps	1.8 Gbps

Source: https://help.sonatype.com/repomanager3/planning-your-implementation/system-requirements

While you likely won‘t need 2 Gbps of throughput on an Orange Pi, these numbers provide a helpful guide for the level of performance you can expect from modest ARM hardware. From my experience, a quad-core 2 GHz ARM SBC with 4 GB RAM can easily handle 50-100 concurrent clients while serving up to 500 Mbps.

Automated Provisioning with Ansible

With sizing decided, it‘s time to deploy Nexus to the Orange Pi. We‘ll use Ansible to fully automate the end-to-end provisioning. This has several key benefits:

1. Consistency: By defining your deployment as code in Ansible playbooks, you can ensure every Nexus instance is configured exactly the same way every time. This eliminates "snowflake servers" and configuration drift.

2. Efficiency: Ansible allows executing complicated provisioning steps from a single command. This saves time and reduces the chances of human error compared to running manual steps.

3. Reproducibility: Ansible playbooks documented your deployment process and make it easy to replicate your setup on new hardware. You can stamp out additional Nexus servers with ease.

4. Simplified Updates: When you need to modify your Nexus config or upgrade to a new version, simply update the Ansible playbooks and re-run them on your fleet. Ansible will determine which steps need to be executed and which can be skipped.

Our Ansible project will be divided into two roles: nexus for configuring the repository server itself, and clients for configuring package managers like pip on client devices to talk to the repository.

Some key tasks handled by the playbooks include:

• Installing OpenJDK, the only external dependency needed by Nexus
• Configuring the Nexus user account and filesystem paths
• Downloading and installing the Nexus app
• Setting up Nexus as a systemd service for automatic start on boot
• Configuring the Nexus app through its REST API, including:
  • Changing default admin password
  • Enabling anonymous read access
  • Creating hosted and proxy repositories
  • Configuring backup and retention policies

Sensitive data like the Nexus admin password are stored in an encrypted Ansible vault to keep them secure while still allowing the playbooks access.

Here‘s an example task for downloading the Nexus package (specific versions omitted):

- name: Download Nexus OSS
  get_url:
    url: "https://download.sonatype.com/nexus/3/latest-unix.tar.gz"
    dest: /opt/nexus-latest-unix.tar.gz
    checksum: "sha256:{{ nexus_download_sha256 }}"

And creating a PyPI proxy repository using the REST API:

- name: Create PyPI proxy repo
  uri:
    url: "http://localhost:8081/service/rest/beta/repositories/pypi/proxy"
    user: admin
    password: "{{ nexus_admin_password }}"
    body_format: json
    body:
      name: pypi-proxy
      online: true
      storage: { blobStoreName: default, strictContentTypeValidation: true }
      proxy: { remoteUrl: ‘https://pypi.org‘ }
      negativeCache: { enabled: true, timeToLive: 1440 }
    force_basic_auth: yes
    status_code: 201  

For a full set of example playbooks, check out the GitHub repo linked at the end of this article.

Advanced Nexus Configuration

With Nexus deployed, there are a variety of ways you can further customize it for your specific needs. Some examples:

• HTTPS: By default, Nexus serves content over HTTP. You can use a reverse proxy like Nginx or Apache to add HTTPS encryption. Or purchase a license for Nexus Pro which includes built-in SSL/TLS support.

• High Availability: For critical workloads, you‘ll want to run Nexus on multiple nodes for redundancy. The easiest way is to set up each node identically using your Ansible playbooks, then use a load balancer to distribute requests between them. In Nexus paid version, you can also cluster the nodes so they present a single logical repository to clients.

• Backup: Nexus maintains all the package files and its own configuration databases on the filesystem under sonatype-work. You‘ll want to back this up regularly. Mount this directory on durable network storage to keep it safe if the node fails. Use Ansible cron module to schedule regular backups.

• Repositories: Nexus supports many different repository formats and types. In addition to proxying public registries, you can host internal packages, or create "group" repositories that present an aggregated view across multiple repos.

• Cleanup Policies: Over time, your repository storage usage will keep growing as you add more and more packages. Configure cleanup policies to automatically delete old versions and snapshots after a certain period. Aim to keep a few months of releases and a few weeks of snapshots.

• Vulnerability Scanning: Paid Nexus versions include Nexus IQ which scans your packages for security vulnerabilities and license issues. For the OSS version, you can use open source tools like OWASP Dependency Check or CoreOS Clair.

I‘ve found the official docs and knowledge base to be very useful in learning about these and other features: https://help.sonatype.com/repomanager3

Choosing Between Proxy and Hosted Repos

One of the key decisions when setting up Nexus is which packages you want to proxy from upstream repositories like PyPI or DockerHub vs hosting internally. Here are some factors to consider:

• Speed: Proxying can be slower since packages need to be fetched from the public repo on first request. But subsequent requests can be served directly from the local cache, making it much faster than going out to the internet each time.

• Availability: If the public registry goes down, you‘ll be unable to download new packages through the proxy. Hosting packages internally ensures they‘re always available (although you should still have a backup).

• Bandwidth: Proxying will use internet bandwidth on the initial request, but save bandwidth for all subsequent requests. Hosting will use your internal network bandwidth.

• Storage: Obviously, hosting requires storing the packages yourself, while proxying offloads this to the public servers. But since you‘ll likely want to keep a local cache anyway, the difference isn‘t as large as it may seem.

• Maintenance: For hosted repos, you need to upload, update, and remove packages yourself. But this gives you full control over which packages are available. Proxying is more hands-off but you‘re at the mercy of the upstream repo.

In practice, most teams will use a mix of proxy and hosted repos. Use proxying for the majority of well-known, stable packages. Host any internal or modified packages. Over time, you may find yourself gradually "promoting" certain proxied packages to internal ones for additional control.

Conclusion

In this guide, we‘ve shown how to deploy the Nexus Repository Manager OSS onto an ARM-based Orange Pi device using Ansible for configuration management. We covered sizing your deployment, provisioning the app, and advanced configuration options.

Artifact repositories like Nexus are a core component of modern DevOps tooling. They enable consistent, reliable access to packages throughout the build and deployment process. With a properly configured Nexus, teams can ensure they‘re using the same versions everywhere, and separate the act of publishing and consuming packages.

Running Nexus on an SBC provides a cost-effective, compact option compared to a full x86 server. While perhaps not suitable for large enterprises, for small to mid-size teams or individual developers it can be a great choice. Performance is very reasonable, while the power, space, and cooling savings are immense.

I encourage anyone interested to try out deploying Nexus on your own Orange Pi or similar device. Start with a basic proof of concept using the Ansible project from this guide, then layer on additional config and features as your comfort grows. Also explore the official docs and other community resources to go deeper on topics like backup, security, etc.

With a little effort, you‘ll soon have a powerful artifact repository that will level up your DevOps automation. You may be surprised how much benefit you can get from this unassuming little device!

Further Reading

• Official Nexus Docs: https://help.sonatype.com/repomanager3

• Nexus on ARM by Jessie Frazelle: https://blog.jessfraz.com/post/nexus-on-arm/

• Example Ansible Playbooks: https://github.com/ConstellationApps/nexus-Orange-Pi