REX-Ray is a container storage orchestration engine enabling persistence for cloud native workloads
APACHE-2.0 License
Published by akutz over 8 years ago
Please see the v0.3.2-RC5 documentation for more information.
Published by akutz over 8 years ago
Please see the v0.3.2-RC4 documentation for more information.
Published by akutz over 8 years ago
Please see the v0.3.2-RC3 documentation for more information.
Published by akutz over 8 years ago
Please see the v0.3.2-RC2 documentation for more information.
Published by akutz almost 9 years ago
--rexrayLogLevel
becomes logLevel
(#196)Pre-Emption is an important feature when using persistent volumes and container schedulers. Without pre-emption, the default behavior of the storage drivers is to deny the attaching operation if the volume is already mounted elsewhere. If it is desired that a host should be able to pre-empt from other hosts, then this feature can be used to enable any host to pre-empt from another.
This release also includes many other small enhancements and bug fixes. For a complete list click here.
Click here for the 0.3.0 binaries.
Published by akutz almost 9 years ago
get
and delete
- ls
and rm
(#107)Published by akutz about 9 years ago
get
and delete
- ls
and rm
(#107)Published by akutz about 9 years ago
Published by akutz about 9 years ago
Published by akutz about 9 years ago
REX-Ray 0.2.0 Release Candidate 4 (RC4)
This release candidate contains the following changes:
stupid
repository has been renamed to unstable
REX-Ray
binary may live wherever, but all of the data is created at the location defined by the environment variable REXRAY_HOME
.$REXRAY_HOME/var/log/rexray/rexray.log
There's not much more to say but that the repository once known as stupid
has been renamed to unstable
. The old stupid
links will continue to work for versions pushed to the repository when it was named such, but once the next release candidate is pushed, those versions will be purged.
The REX-Ray
binary now supports the install
and uninstall
commands, executed as rexray install
or rexray uninstall
. These commands install the REX-Ray
service if on a Linux system. Additionally, the install
and uninstall
commands are also what is used by the RPM and DEB packages, meaning that the REX-Ray
installer is distribution and package agnostic.
The Makefile now has support for the following targets:
The above targets do what they imply they do -- they assemble the REX-Ray binary into an RPM or DEB package. Please note the above targets expect the appropriate architecture of REX-Ray to already be built and will not force a new build of REX-Ray.
Also, it's not without much trouble that building a 32-bit DEB package is possible on a 64-bit system, and thus the 32-bit DEB package is not available at this time. Since alien
was used to create the DEB packages from the RPMS, the 32-bit RPM could easily be converted to a 32-bit DEB if a 32-bit Debian system were available.
The packages install REX-Ray
and register its service, but the server is not started.
REXRAY_HOME
The REX-Ray
binary can exist anywhere on a system, but when it is executed it assumes the following paths (and will create them if they do not exist):
$REXRAY_HOME/etc/rexray
$REXRAY_HOME/var/lib/rexray
$REXRAY_HOME/var/log/rexray
$REXRAY_HOME/var/run/rexray
If the REXRAY_HOME
environment variable does not exist then the above paths will exist within the filesystem layout standard for both almost any UNIX-derived system such as Linux or Darwin (OS X).
However, defining REXRAY_HOME
to be /opt/rexray/0.2.0
means that all four paths above will be created and expected to exist at /opt/rexray/0.2.0
.
Again, the REX-Ray
binary can reside in /usr/bin
, /opt/rexray/0.2.0/usr/bin
, at /
, or anywhere on the filesystem. The binary's location is independent of where the data is stored.
When REX-Ray
is executed as a service the logs are no longer emitted to stdout
(except for SystemD
where they are, but not limited to there). Instead the logs are written to $REXRAY_HOME/var/log/rexray/rexray.log
.
Of note, when logs are emitted to stdout
they are color-coded, but not so when written to a log file.
Published by akutz about 9 years ago
Published by akutz about 9 years ago
Published by akutz about 9 years ago
The first release candidate for 0.2.0 introduces many improvements to the REX-ray
tool at a core level in order to lower REX-ray
's barrier of entry to bloggers, end-users, systems administrators, and software engineers.
All changes introduced by this commit should be considered breaking changes and updates to existing documentation is required.
REX-ray
now includes built-in support for installing itself as a service on Linux distributions that support either SystemV or SystemD initialization systems. This feature has been tested successfully on both CentOS 7 Minimal (SystemD) and Ubuntu 14.04 Server (SystemV) distributions.
To install REX-ray
on a supported Linux distribution, all that is required now is to download the binary and execute:
sudo ./rexray service install
What does that do? In short the above command will determine if the Linux distribution uses systemctl, update-rc.d, or chkconfig to manage system services. After that the following steps occur:
The path /opt/rexray is created and chowned to root:root with permissions set to 0755.
The binary is copied to /opt/rexray/rexray and chowned to root:root with permissions set to 4755. This is important, because this means that any non-privileged user can execute the rexray binary as root without requiring sudo privileges. For more information on this feature, please read about the Linux kernel's super-user ID (SUID) bit.
Because the REX-ray
binary can now be executed with root privileges by non-root users, the binary can be used by non-root users to easily attach and mount external storage.
The directory /etc/rexray is created and chowned to root:root.
The next steps depends on the type of Linux distribution. However, it's important to know that the new version of the REX-ray
binary now supports managing its own PID (at /var/run/rexray.pid
) when run as a service as well as supports the standard SysV control commands such as start
, stop
, status
, and restart
.
For SysV Linux distributions that use chkconfig
or update-rc.d
, a symlink of the REX-ray
binary is created in /etc/init.d
and then either chkconfig rexray on
or update-rc.d rexray defaults
is executed.
Modern Linux distributions have moved to SystemD for controlling services. If the systemctl
command is detected when installing REX-ray
then a unit file is written to /etc/systemd/system/rexray.servic
e with the following contents:
[Unit]
Description=rexray
Before=docker.service
[Service]
EnvironmentFile=/etc/rexray/rexray.env
ExecStart=/opt/rexray/rexray service start
ExecStart=/opt/rexray/rexray service stop
KillMode=process
Restart=always
StartLimitInterval=0
[Install]
WantedBy=docker.service
Additionally, an environment file (and parent directory) is created at /etc/rexray/rexray.env with the contents:
REXRAY_HOME=/opt/rexray
The REX-ray
service is not started immediately upon installation. The install command completes by informing the users that they should visit the REX-ray
website for information on how to configure REX-ray
's storage drivers. The text to the users also explains how to start the REX-ray
service once it's configured using the service command particular to the Linux distribution.
This release also removes the need for REX-ray
to be configured as multiple service instances in order to provide multiple end-points to such consumers such as Docker
. REX-ray
's backend now supports an internal, modular design which enables it to host multiple module instances of any module, such as the DockerVolumeDriverModule. In fact, one of the default, included modules is...
The AdminModule enables an HTTP JSON API for managing REX-ray
's module system as well as provides a UI to view the currently running modules. Simply start the REX-ray
server and then visit the URL http://localhost:7979 in your favorite browser to see what's loaded. Or you can access either of the currently supported REST URLs:
http://localhost:7979/r/module/types
and
http://localhost:7979/r/module/instances
Actually, those aren't the only two URLs, but the others are for internal users as of this point. However, the source is open, so... :)
If you want to know what modules are available by using the CLI, after starting the REX-ray
service simply type:
[0]akutz@poppy:rexray$ rexray service module types
[
{
"id": 2,
"name": "DockerVolumeDriverModule",
"addresses": [
"unix:///run/docker/plugins/rexray.sock",
"tcp://:7980"
]
},
{
"id": 1,
"name": "AdminModule",
"addresses": [
"tcp://:7979"
]
}
]
[0]akutz@poppy:rexray$
To get a list of the running modules you would type:
[0]akutz@poppy:rexray$ rexray service module instance get
[
{
"id": 1,
"typeId": 1,
"name": "AdminModule",
"address": "tcp://:7979",
"description": "The `REX-ray` admin module",
"started": true
},
{
"id": 2,
"typeId": 2,
"name": "DockerVolumeDriverModule",
"address": "unix:///run/docker/plugins/rexray.sock",
"description": "The `REX-ray` Docker VolumeDriver module",
"started": true
},
{
"id": 3,
"typeId": 2,
"name": "DockerVolumeDriverModule",
"address": "tcp://:7980",
"description": "The `REX-ray` Docker VolumeDriver module",
"started": true
}
]
[0]akutz@poppy:rexray$
Hmmm, you know, the REX-ray
CLI looks a litle different in the above examples, doesn't it? About that...
The CLI has also been enhanced to present a more simplified view up front to users. The commands are now categorized into logical groups:
[0]akutz@pax:~$ rexray
REX-Ray:
A guest-based storage introspection tool that enables local
visibility and management from cloud and storage platforms.
Usage:
rexray [flags]
rexray [command]
Available Commands:
volume The volume manager
snapshot The snapshot manager
device The device manager
adapter The adapter manager
service The service controller
version Print the version
help Help about any command
Global Flags:
-c, --config="/Users/akutz/.rexray/config.yaml": The REX-Ray configuration file
-?, --help[=false]: Help for rexray
-h, --host="tcp://:7979": The REX-Ray service address
-l, --logLevel="info": The log level (panic, fatal, error, warn, info, debug)
-v, --verbose[=false]: Print verbose help information
Use "rexray [command] --help" for more information about a command.
REX-ray
now supports Travis-CI builds either from the primary REX-ray
repository or via a fork. All builds should be executed through the Makefile, which is a Travis-CI default. For the Travis-CI settings please be sure to set the environment variable GO15VENDOREXPERIMENT
to 1
.
Published by clintkitson over 9 years ago
added clone from volume