Can Nexus or Artifactory store simple tar.gz artifacts?

Question

I have cloud servers located in separate data centers across the world. Each data center is separate from the others.

I'm looking for an easy way to deploy artifacts to individual clusters of servers (that may be running different versions of software i.e. a dev, test, and production cluster) in each of these regions with ease and consistency. It seems to me that an artifact server is what I need because I could execute an install script on the cloud server, which pulls down the correct software artifact.

Now, I work on the operations side. I don't care about doing builds, or managing software build dependencies. I simply want an artifact server where I can store all the different versions of my packages for access at a later time. The kicker, is that I have several different types of artifacts to store.

• Shell scripts
• Python scripts
• Puppet manifests
• Debian files (often delivered as a tar.gz file of multiple debians)

Can Nexus or Artifactory manage all of these types of packages, or should I be looking in a different direction? I'm not opposed to adding make files to my shell script projects that simply generate tar.gz files. I just don't want to go down the path of setting up an artifact repository, when ultimately, a little scripting, wget, and an apache server would work just fine.

Solution 1

Both Artifactory and Nexus can handle any type of file, as they both are "Binary Repository Managers".

Albeit that, Nexus can technically store any file, but lacks support for binaries that do not adhere to the Maven repository layout. For example, such files will not be indexed and cannot be retrieved in searches; Also, if non-Maven artifacts encumber module information in their path, then currently Artifactory is the only repository that can make use of that and allow version based operations on artifacts (e.g., download latest version query)

Although both of these tools have started out by solving a problem in the Maven world, the need for smart binary management has been recognized in many other fields, operations included.

Binaries do need a specialized manager, and although network shares/SCM/file servers seem like a viable option in the beginning; they just don't scale.

Also see my answer to a similar question for some of the benefits of a manager over the other ad-hoc solutions.

Solution 2

Yes, you can upload non-jar files. For example:

mvn deploy:deploy-file -DgroupId=org.group.id -DartifactId=artifact-id -Dversion=0.0.0.1-SNAPSHOT -Dpackaging=tar.gz -DrepositoryId=repository-id -Durl=http://url -Dfile=localfile-0.0.0.1-SNAPSHOT.tar.gz

Newer versions of Nexus will handle certain files like tar, swf, and others by validating that they are properly formed. This may cause unexpected or unwanted behavior, though.

Is this the best way to go... only you can say based on your use cases. Factors like how often artifacts change, network latency, and others can make or break a strategy.

refs:

https://stackoverflow.com/a/33311645/32453

http://betterlogic.com/roger/2012/04/mavennexus-upload-tgztar-gz-file/