Skip to content

Latest commit

 

History

History
127 lines (96 loc) · 10.3 KB

How-To-Host-Feed.md

File metadata and controls

127 lines (96 loc) · 10.3 KB
Raw

How To Host Your Own [Private/Internal/Public] Package Repository Server (aka Package Feed)

Why?

Please read [[Depending on the chocolatey.org as an organization|ChocolateyFAQs#should-my-organization-depend-on-use-the-community-feed-httpschocolateyorgpackages]]

Host your own server

There are three types of package repositories, folder/unc share, simple server, and the sophisticated package gallery.

Alternative Hosting Options (that require less work/maintenance):

  • MyGet - MyGet has free public and paid for public/private cloud-hosting options if you don't want to handle all of the pain of setup and administration. MyGet offers some stellar options like multi-feed aggregation, mirroring, and source package build services!
  • ProGet - ProGet gives you a ready to go On-Premise option (installable with Chocolatey!).
  • Artifactory - see Artifactory NuGet Repositories - not in the free version
  • TeamCity has built-in Simple Server
  • Nexus - Sonatype Nexus has a built-in simple server

Package Version Immutability

A package version is immutable on some sources. This means that everybody's version 1.0.1 of a particular package is the same. You do not need to worry about this when updating with newer versions of packages, because each package version compiled nupkg has the unique version in the name (e.g bob.1.0.0.nupkg vs bob.1.0.1.nupkg ).

Package immutability is usually desired, because then you know that everyone on v1.0.0 of a package has exactly the same code as does even everyone else. Even a broken version v1.0.0 gives you a global understanding that everyone who has v1.0.0 has exactly the same bits. This really simplifies administration. Without immutability, there is no guarantee that a version of a package installed is the same as the version of the package at the source.

Local Folder / UNC Share (CIFS)

Perhaps the easiest to set up and recommended for testing quick and dirty scenarios, local folder is easily a strong point when you need a quick source for packages.

Advantages:

  • Speed of setup (can be setup almost immediately).
  • Package store is filesystem.
  • Can be easily upgrade to Simple Server.
  • Permissions are based on file system/share permissions.
  • There is no limitation on package sizes (or rather, it can likely handle 100MB+ file sizes, maybe even GB sized packages). Don't create multiple GB sized packages, what is wrong with you?! ;)

Disadvantages:

  • Anyone with permission can push and overwrite packages.
  • No HTTP/HTTPS pushing. Must be able to access the folder/share to push to it.
  • Starts to affect choco performance once the source has over 500 packages (maybe?).
  • Big disadvantage: For a file share there is not a guarantee of package version immutability. Does not do anything to keep from package versions being overwritten. This provides no immutability of a package version and no guarantee that a version of a package installed is the same as the version in the source.

Local Folder Share Setup

No really, it's that easy. Just set your permissions appropriately and put packages in the folder. You are already done.

Simple Server

There is where the bulk of NuGet OData compatible servers fall (Nexus, Nuget.Server, Chocolatey.Server, Artifactory, MyGet, etc). Since Chocolatey just uses an enhanced version of the NuGet framework, it is compatible everywhere you can put a NuGet package.

Advantages:

  • Setup can be really simple - just a website and IIS for some simple servers.
  • Windows is not required - there are at least two pure Java versions (see Non-Windows Hosting).
  • Push over HTTP/HTTPS.
  • API key for pushing packages.
  • No direct access to packages so security can be locked down to just modify through push.
  • Package store is file system.

Disadvantages:

  • Only one API key, so no multi user scenarios.
  • Starts to affect choco performance once the source has over 500 packages (maybe?).
  • No moderation.
  • No website to view packages.
  • No package statistics.
  • A package should may be limited to 28.61MB by default on some simple servers. Depending on your simple server - For IIS simple servers package size can be controlled through maxAllowedContentLength and maxRequestLength. For others like Nexus, it may already be set very high. You can host the installer internally somewhere and access it through packaging though.

The actual limit for package sizes varies depending on what each simple server can handle (usually determined by the limitation of pushing a package to the server). If you determine what those are, we'd be happy to list each one here.

Simple Server Setup

Many google searches will throw out good ways to set up your own feed (hint: search for host your own nuget server feed)

Some notable references:

Chocolatey Server Setup

Chocolatey Server is a simple Nuget.Server that is ready to rock and roll. It has already completed Steps 1-3 of NuGet's host your own remote feed. Version 0.1.2 has the following additional adds:

  • Uses same enhanced NuGet that Chocolatey uses so you can see more information in search if you choose to use those things.
  • Allows packages up to 2GB. Package size can be controlled through maxAllowedContentLength and maxRequestLength.

Set it up:

  1. Install the Chocolatey Server package - choco install chocolatey.server -y
  2. Configure IIS appropriately for the package.
  3. Be sure to give the app pool modify permissions to the App_Data folder.

Alternative means of installation? If you have Puppet, you can take a look at the chocolatey server module.

Package Gallery

This is like what https://chocolatey.org (the community feed runs on). It is the most advanced, having both a file store for packages and a database for tracking all sorts of information.

Advantages:

  • Can deal with thousands of packages with no performance issues.
  • Package versions are immutable - in other words you can guarantee the version installed is the same as the version in the source.
  • Package store can be File system, Azure blobs, or AWS S3 (Chocolatey Package Gallery only).
  • Multiple users each having their own API keys.
  • User registration with email confirmation.
  • Interaction and collaboration based.
  • Can have administrators.
  • Can take advantage of moderation (Chocolatey Package Gallery only).
  • Package statistics (download counts, etc).
  • A website to view package information.
  • Can be configured to send email.

Disadvantages:

  • Speed of setup (can take longer than the rest). There are many moving parts to configure.
  • Requires Windows/IIS/SQL Server/SMTP (hopefully with the proper licenses on each of those).
  • Not well-documented, could require some diligence to get working.
  • A package should not be bigger than 150MB. You can host the installer internally somewhere and access it through packaging though. Package size can be controlled through maxAllowedContentLength and maxRequestLength.

Package Gallery Setup

Only approach this if you are a Windows Admin with significant experience in setting up SQL Server databases and IIS for ASP.NET MVC sites. We don't have resources to help support the setup, but we can point you to NuGet Gallery Setup.

Chocolatey Package Gallery Setup

At this time we don't have setup instructions and are not keen to answer questions specifically surrounding the setup of a Chocolatey Gallery (the code behind chocolatey.org). This is due to specific necessary settings regarding the community packages repository and tight integration to what it offers. Chocolatey for Business is likely to offer a gallery at some point, depending on prioritization.

Non-Windows Hosting

If you don't want to host on Windows you have only the following options (from least advanced to most advanced - these options typically also work on Windows):

Note: NuGet.Java.Server, TeamCity and JNuGet are about the same in terms of sophistication (they are ordered alphabetically).