(mOSAIC) Packages
Contents
Proposal
Big picture
Each organization, team, or individual developer -- that we shall call from now on just "developer" -- that wants to deploy an application is required to host one or multiple mOSAIC package repositories. (This has been greatly inspired by Java's Maven artifacts.)
Packages are nothing else than a group of files organized into directories, and maybe some accompanying meta-data. The packages can be of many types, like for example:
- Source code packages, gathering all the files that are used to generate a particular binary package. Of course this doesn't replace the versioning systems like SVN, Git or Mercurial, it just presents a snapshot of the source code used for a particular build.
- Byte-code packages, portable between operating systems and architectures, like for example Java jar files, or other similar ones.
- Operating system packages, specific to a particular OS and architecture.
- Anything that can be called a "package".
Each package is identified by the following coordinates (again inspired by Maven):
- A "group" identifier (in Maven "groupId") which gathers together related packages. For example all packages belonging to the same application, and are developed by the developer, are part of the same group, and perhaps some reusable libraries are put in a different one. At the same time we, as the mOSAIC developers, have our own group.
- An "artifact" identifier (in Maven "artifactId") which names a particular software product, like a component, library, etc.
A "version" identifier (in Maven "version") which is self explanatory, but which should follow the SemVer schema.
- A "type" identifier (in Maven "packaging") denoting the purpose and structure of the package, for example source code, documentation, Debian package, RPM package, etc.
- Additional, optional, identifiers depending on the type, like for example the architecture in case of binary packages, etc.
There are always at least two related package repositories (as inspired by DVCS tools like Git or Mercurial):
- a local repository on the developers workstation where he imports the actual package contents;
- a remote repository, where he pushes the prepared packages, to be accessible by the deployment tools;
The packages are imported, and pushed into repositories by the usage of a custom mOSAIC tool, which we'll describe shortly, but the repositories are accessed by all the other tools (like for example the deployer) as either:
- a simple HTTP exported file system, where one package is exported, depending on the package's type, as single archive file, for example a Jar, Zip, Deb, RPM, etc.
- but the meta data is also exposed as a CouchDB database, which will allow dynamic queries or even generate the needed listings for various packaging systems (as for example dpkg, rpm, pacman, etc.).
The frontend tool
Similar with Git or Mercurial there is only one tool which has multiple sub commands used to manage the local repository and push to the remote one. For example:
- initializing a new packages repository:
mpr initialize --store /data/mosaic-packages
- importing a new package into the local repository:
mpr import --package eu.mosaic_cloud.components/rabbitmq/1.0.2/mos/x86_32 --path /tmp/mosaic-builds/rabbitmq
- publishing a package to the remote repository:
mpr publish --package eu.mosaic_cloud.components/rabbitmq/1.0.2/mos/x86_32
Security consideration
The security concerns are twofold: confidentiality and access control.
The confidentiality is solved by employing TLS at the transport layer, thus no further discussions are needed.
Access control is again split in two: authentication and authorization. Authentication is solved by either employing X.509 certificates, or just in the case of the HTTP access of packages through "secret" tokens that can be transmitted to trusted parties. The authorization is done at repository level, with only two rights: read of any packages stored within, or write in a similar manner.