Posts

Showing posts from October, 2017

Running Pods as Anyuid in Openshift Origin

When using Openshift Origin, by default all pods are running with 'restricted' context, where they are forced to use a generated user id. Some Containers just doesn't work that way, so we need to relax the restriction a bit. Reference :  https://blog.openshift.com/understanding-service-accounts-sccs/ Creating A service account First, create a service account in your project (see https://docs.openshift.com/enterprise/3.0/admin_guide/manage_scc.html ). These are a sample yaml to do that : kind: ServiceAccount apiVersion: v1 metadata: name: mysvcacct Note that underscore are not allowed as service account name despite the official openshift example contains it. Assigning anyuid Then, a cluster administrator should login to the project and assign anyuid SCC : oc login oc project theproject oc adm policy add-scc-to-user anyuid -z mysvcacct Using the service account Now, edit the deployment config or the replication controller config to use the serv

Cleaning Openshift Origin Images Registry

Image
When using and tending an Openshift Origin cluster (for example, Origin version 3.7), it is normal to start the storage allocation in small sizes. However soon we find that storage for registry get filled up quickly with images from each build process. This post will show how to clean them up. Preparation before pruning First you need oc (origin client) binary and a user account with cluster administration capability. If the openshift docker registry  is installed inside the cluster without external access, then you also going to need OS access to one of the hosts inside the cluster. First step is to login to the cluster from your client or inside one of the hosts: oc login Prune steps Reading the documentation (https://docs.openshift.com/enterprise/3.0/admin_guide/pruning_resources.html) we find that the pruning starts at deployment, then builds, and last images. Pruning Deployment  Run this to preview which deployment are going to be pruned: oc adm prune deploy

Lessons Upgrading MySQL DB 5.1 to Percona 5.7

I just recently upgraded a database server that were previously running MySQL 5.1 (standard, Sun/Oracle version) into Percona Server 5.7. A few quirks notable enough to warrant this blog post. Planning and Preparation A Percona blog post ( mysql-upgrade-best-practices ) stated that the best way to upgrade with such huge difference in major version (5.1 to 5.7) is to do a full logical dump for all database except mysql, dump user and grants, uninstall database and remove datafiles, then install new version and import the logical dump and grants. But alas the database we are going to upgrade is so big and the IO subsystem became some sort of bottleneck when doing logical dump, our colleagues tried to do mysqldump and it tooks more than 2 days to run, prompting us to cancel the backup (otherwise it would interfere with workday application usage of the database).  Reading the blog I noted that : for major version upgrade, using logical dump  and restore dump is the safest way to