https://github.com/springerpe/nfsclient-boshrelease
Simple NFS client boshrelease
https://github.com/springerpe/nfsclient-boshrelease
Last synced: about 1 year ago
JSON representation
Simple NFS client boshrelease
- Host: GitHub
- URL: https://github.com/springerpe/nfsclient-boshrelease
- Owner: SpringerPE
- License: apache-2.0
- Created: 2021-11-02T16:08:06.000Z (over 4 years ago)
- Default Branch: main
- Last Pushed: 2021-12-21T12:15:03.000Z (over 4 years ago)
- Last Synced: 2025-01-14T04:44:35.303Z (over 1 year ago)
- Language: Shell
- Size: 39.1 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE.md
Awesome Lists containing this project
README
# BOSH Release for nfsclient
This is a workaround to be able to use bionic nfs services. The idea is use official distribuiton packages instead
of shipping Debian packages with the release (which breaks the philosophy of a linux distribution and also the philosophy of Bosh)
For now it is focused on Ubuntu stemcells.
## Usage
The parameters are compatible with the `nfs_mounter` job of bosh `capi-release`.
It also creates the `shared` folder and the file `/shared/.nfs_test` to check if it is
writable (the file is used in other releases -like CAPI- for checking everything is ok).
Given this manifest:
```
---
name: nfs-test
releases:
- name: nfsclient
version: latest
stemcells:
- alias: xenial
os: ubuntu-xenial
version: latest
- alias: bionic
os: ubuntu-bionic
version: latest
instance_groups:
- name: bionic
instances: 1
vm_type: small
stemcell: bionic
vm_extensions: []
azs:
- z1
- z2
- z3
networks:
- name: default
jobs:
- name: nfsclient
release: nfsclient
properties:
nfs_server:
address: "10.10.0.1"
share: "/blobstore"
share_path: '/var/vcap/data/nfs'
nfsv4: false
apt_packages:
- rpcbind: "0.2.3-0.6"
- keyutils: "*"
- nfs-common: "1:1.3"
- name: xenial
instances: 1
vm_type: small
stemcell: xenial
vm_extensions: []
azs:
- z1
- z2
- z3
networks:
- name: default
jobs:
- name: nfsclient
release: nfsclient
properties:
nfs_server:
address: "10.10.0.1"
share: "/blobstore"
share_path: '/var/vcap/data/nfs'
nfsv4: false
update:
canaries: 1
max_in_flight: 1
serial: false
canary_watch_time: 1000-60000
update_watch_time: 1000-60000
```
Two vms will be created. The first one is using a ubuntu-bionic stemcell and the versions of the packages are specificed.
The version of `rpcbind` matches a version so that one will be installed. In the case of `nfs-common` the version does not
match a full version, but it matches with mayor versions (like `1:1.3.4-2.1ubuntu5.3` `1:1.3.4-2.1ubuntu5.5` and `1:1.3.4-2.1ubuntu5`)
so the latest one (bigger) will be installed (`1:1.3.4-2.1ubuntu5.5`). Also both packages will will be marked for hold, so no
updates will be installed even if they are available.
The xenial one (second instance) will have the nfs packages installed with the latest available version in the distribution
(after doing `apt-get update` -by default-).
# Developing
Blobs of this release are stored in this git repository in the folder `blobstore`. The idea was taken from here: https://starkandwayne.com/blog/bosh-releases-with-git-lfs/
After this, files created by `bosh create-release --final` can be committed to the repo with git commit and it will be stored with git lfs. No need run `bosh sync-blobs`, instead just `git commit && git push`. All of these steps are automatically done by the script `create-final-public-release.sh`.
When do a git commit, try to use good commit messages; the release changes on each release will be taken from the commit messages!
## Creating Dev releases (for testing)
To create a dev release -for testing purposes-, just run:
```
# Create a dev release
bosh create-release --force --tarball=/tmp/release.tgz
# Upload release to bosh director
bosh -e upload-release /tmp/release.tgz
```
Then you can modify your manifest to include `latest` as a version (no `url` and `sha` fields are needed when the release is manually uploaded):
```
releases:
[...]
- name: nfsclient
version: latest
```
Once you know that the dev version is working, you can generate and publish a final version of the release (see below), and remember to change the deployment manifest to use a url of the new final manifest like this:
```
releases:
[...]
- name: nfsclient
url: https://github.com/SpringerPE/nfsclient-boshrelease/releases/download/v8/nfsclient-8.tgz
version: 8
sha1: 12c34892f5bc99491c310c8867b508f1bc12629c
```
or much better, use an operations file ;-)
## Creating a new final release and publishing to GitHub releases:
Run: `./create-final-public-release.sh [version-number]`
Keep in mind you will need a Github token defined in a environment variable `GITHUB_TOKEN`. Please get your token here: https://help.github.com/articles/creating-an-access-token-for-command-line-use/
and run `export GITHUB_TOKEN="xxxxxxxxxxxxxxxxx"`, after that you can use the script.
`version-number` is optional. If not provided it will create a new major version (as integer), otherwise you can specify versions like "8.1", "8.1.2". There is a regular expresion in the script to check if the format is correct. Bosh client does not allow you to create 2 releases with the same version number. If for some reason you need to recreate a release version, delete the file created in `releases/nfsclient-boshrelease` and update the index file in the same location, you also need to remove the release (and tags) in Github.
# Usage in a deployment manifest
This is and add-on release, it will work only if it is deployed together with the
*prometheus-boshrelease* on the nodes.
Considering v2 manifest style, add the new releases in the `releases` block:
```
releases:
[...]
- name: nfsclient
version: latest
```
then in your `instance_groups`, add:
```
instance_groups:
[...]
jobs:
[...]
- name: nfsclient
release: nfsclient
```
# Author
SpringerNature Platform Engineering, José Riguera López (jose.riguera@springer.com)
Copyright 2017 Springer Nature
# License
Apache 2.0 License