<style> .present { text-align: left } .present h2 { text-align: center } </style> # Nexus (ASDF 4-Jul-2019) Introducing the Nexus application template and Software Component Repository service --- ## What is Nexus? Software development involves various artifacts (= by-products), in particular: * binaries * distribution packages (RPMs, Docker images, WAR...) * dependencies (libraries...) Nexus is a web app to store and organize these artifacts within _repositories_. --- ## History Many ad-hoc instances of Nexus/Artifactory. Prototype of centrally hosted Nexus instances cf. [November 2018 ASDF](https://indico.cern.ch/event/770202/) - a few early adopters. Production in January 2019 with minor bugfixes. SNow: [_Software Component Repository service_](https://cern.service-now.com/service-portal/service-element.do?name=soft-comp-rep) --- ## What is offered * Self-service application template in Openshift * Preconfigured with SSO, e-groups, S3 storage, backup etc. IT-CDA provides the infrastructure, maintains the template and deploys security updates. Instance owners have full control on the configuration. --- ## Main use cases (rephrased) 1. Manage artifacts _produced_ by software development * help with code reuse (components/libraries), build process * one Nexus instance per large project/developer team 2. Manage artifacts _consumed_ by software development * external dependencies (public repositories...) * opportunity to centralize access --- ## External dependencies Software projects typically use a large number of existing libraries. They come from various public repositories, just a few big ones: * EPEL: RPM packages (all languages - Yum repo format) * pypi.org: PyPI packages (Python) * Maven central: Maven repository (Java) --- ## Challenges with public repos See [Computer Security article in Feb'19 Bulletin](https://home.cern/news/news/computing/computer-security-fatal-dependencies) * identify a project's dependencies * availability of specific version X.Y.Z * vulnerabilities * malicious takeover of package ownership --- ## Nexus as a repository proxy * Centralize access to public repos * Identify what external libraries have been used * Local copy of specific versions * Whitelist/blacklist sources Typically set up by each developer team on the same Nexus/Artifactory instance used to store the artifacts they produce. --- ## Central repo proxy? * [linuxsoft](http://linuxsoft.cern.ch/) provides curated local mirror of Yum repositories * [CNIC](http://information-technology.web.cern.ch/about/meeting/cnic-meetings) expressed interest in similar functionality for other repo formats: PyPI, Maven... * Nexus might be an option to provide such functionality --- ## Nexus as a central repo proxy Interesting: * Readily available, infrastructure, updates Possible challenge: * Limited options for scaling/HA in OSS version Whatever the technical solution: * Preconfigure each developer team's Nexus instance to use central proxy as upstream * Curator needed to maintain list of sources, whitelist/blacklist --- ## Software distribution * Nexus can act as a software distribution point * Non-RPM package formats (RPM = linuxsoft) * E.g. reuse in-house libraries across teams * Interest in federating them in a central distribution point? ```graphviz digraph distribution { rankdir=LR; "nexus-devteam1/public" -> "cern-software-repo/devteam1,2..."; "nexus-devteam2/public" -> "cern-software-repo/devteam1,2..."; "nexus-.../public" -> "cern-software-repo/devteam1,2..."; } ``` --- ## Summary * IT now offers central hosting of Nexus instances * self-service, per developer team * previously required ad-hoc installations * May also be the foundation of new central services * control access to external libraries * distribute CERN software