Geolocation on Google Kubernetes Engine

Problem statement:

If you run your Webite or eCommerce Platform on Kubernetes, you might experience problems with geolocating the addresses of your visitors and potential customers.
A potential cause for this issue is, that you have exposed your app  through a service of type: LoadBalancer and your Kubernetes Container cannot see the original source IP addresses of the visitors.

Solution:

This solution describes how to preserve client IP addresses on Google Kubernetes Engine (GKE) for services of type: LoadBalancer.
Note: This is especially required if you need to geolocate visitor addresses e.g. in order to display correct taxes (like done by GT4M – Global Tax for Marketplace and More).

Set the externalTrafficPolicy to Local in your Service configuration as follows:

apiVersion: v1
kind: Service
metadata:
  name: <yourapp-service>
spec:
  selector:
    app: <yourapp>
  ports:
    - port: <port>
      targetPort: <targetport>
  externalTrafficPolicy: Local
  type: LoadBalancer

That’s all 🙂

Need further support or Kubernetes Consulting?

Please checkout our Consulting hours.

You don’t want to go into technical details anymore?

Check out the Blue Antoinette Commerce Cloud, which is built on and abstracts away the complexities of Kubernetes.

Global Tax 4.0 is here!

Global Tax 4.0

We are more than happy to announce the availability of Global Tax 4.0 today.

Global Tax 4.0 is a major release and an important step towards our Multi Cloud Strategy on Kubernetes clusters.

This update covers Global Tax as a Service that was previously only available in the Google Cloud and in the Blue Antoinette Commerce Cloud and enables it to run on any cloud as well as On Premise.

Furthermore it comes with compatibility updates of all of our currently available Global Tax Solutions for dedicated Online shops and Multivendor Marketplaces.

Note: Existing customers are not necessarily required to upgrade unless they upgrade their shop or marketplace software to the latest release or if they have Google Site Kit installed and experience compatibilty issues.

New customer learn more at GT4M (gt4m.com) or check out our solutions at Blue Antoinette (blueantoinette.com) now.

The Blue Antoinette Commerce Cloud is here

Blue Antoinette Commerce Cloud

We are more than happy to announce the availablity of the Blue Antoinette Commerce Cloud today.

The Blue Antoinette Commerce Cloud enables you to start an online shop or a multivendor marketplace in no time and at low costs.

As of today we provide the following online services which enable you to operate two widely used open source eCommerce platforms.

  • WooCommerce as a Service is an Online Service in the Blue Antoinette Commerce Cloud, which enables you to run an WooCommerce based Online Shop within seconds.
  • Dokan as a Service is an Online Service in the Blue Antoinette Commerce Cloud, which enables you to run an Dokan based Multivendor Marketplace within seconds.

Furthermore customers get unlimited  access to publicly available plugins as well as to plugins and services in the Blue Antoinette Marketplace, like the unique

  • Global Tax as a Service which is a Tax Calculation REST API and powerful backend for Online Shops and Marketplaces enabling you to calculate and collect indirect taxes worlwide.

We also support bringing your own licenses (BYOL) of other eCommerce platforms to the Blue Antoinette Commerce Cloud.

The Blue Antoinette Commerce Cloud is built on

  • and abstracts away the complexities of Kubernetes, the leading open-source platform for managing containerized workloads and services backed by Google
  • Kubernetes App Builder developed by Blue Antoinette Business Solutions
  • Multi Tenancy Cloud Server for WordPress developed by Blue Antoinette Business Solutions

Head over to the Blue Antoinette – Site now and check out the Blue Antoinette Commerce Cloud.

 

Persistance of Linux Users in Kubernetes Pods

Problem statement:

Linux users which are dynamically created in Kubernetes Containers are not persistant. Therefore, whenever a Kubernetes Pod gets restarted, the dynamically created users are lost.

For example, if you want to run multiple vhosts in a Kubernetes Container under separate UIDs and GIDs with apache2-mpm-itk (which is an MPM – Multi-Processing Module for the Apache web server), a solution for persisting Linux users like the following is required:

Solution:

This solution desribes how to survive Kubernetes Pod restarts by dynamically recreating Linux users in a Kubernetes container whenever a new pod is created.

  1. Create a Kubernetes ConfigMap (or Secret) for storing custom users:
    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: my-linux-users
    data:
     linux-users: ""
  2. Create a script which reads the custom users from the ConfigMap mounted in /etc/linux-users and which recreates the users when the pod is restarted. Store the script in another Kubernetes ConfigMap as follows:
    apiVersion: v1
    kind: ConfigMap
    metadata:
     name: my-sync-script
    data:
     install-linux-users.sh: |
       # Install existing linux users mounted from configmap in /etc/linux-users - file
       echo "Install Linux Users..."
       cat /etc/linux-users | awk -F ":" '{ system("groupadd "$1""); system("useradd -c "$5" -s /usr/sbin/nologin -d "$6" -m -g "$4" "$1"")}'
  3. Mount the Kubernetes ConfigMaps in your StatefulSet (or Deployment) where your container resides (excerpt)
    apiVersion: apps/v1
    kind: StatefulSet
    spec:
     containers:
     - image: ...
       name: ...
       volumeMounts:
       - name: linux-users
         mountPath: /etc/linux-users
         subPath: linux-users
         readOnly: true
       - name: install-conf
         mountPath: /usr/local/bin/install-linux-users.sh
         subPath: install-linux-users.sh
         readOnly: true
     volumes:
     - name: linux-users
         configMap:
         name: my-linux-users
         items:
         - key: www-users
           path: www-users
     - name: install-conf
         configMap:
         name: my-sync-script
         items:
         - key: install-linux-users.sh
           path: install-linux-users.sh
  4.  Hook into the postStart – Event when a container is created and run the script which recreates the users
    ....
     lifecycle:
       postStart:
         exec:
           command:
           - "/bin/bash"
           - "-eu"
           - "/usr/local/bin/install-linux-users.sh"
  5. Whenever you create a Linux user in your Kubernetes container, get a custom user list from the /etc/passed -file and save in a temp directory.
     # Create linux user
     groupadd ${WWW_GROUP}"
     useradd -c ${WWW_COMMENT} -s /bin/false -d /home/${LINUX_USER} -m -g ${WWW_GROUP} ${WWW_USER}"
     # Save custom linux-users (filtered by a common comment) in a temp directory.
     grep ${WWW_COMMENT} /etc/passwd >${LINUX_USERS_FILE}
  6. Get the list of your linux users from the container
    kubectl cp ${NAMESPACE}/${WEBSERVER_POD}:${LINUX_USERS_FILE} ${LOCAL_LINUX_USERS_FILE} -c ${WEBSERVER_CONTAINER}
  7. # Update the configmap with the linux-users – file
    kubectl create configmap my-linux-users --namespace=${NAMESPACE} --from-file=${LOCAL_LINUX_USERS_FILE} --save-config -o=yaml --dry-run | kubectl apply -f -

 

Need further support or Kubernetes Consulting?

Please checkout our Consulting hours.

You don’t want to go into technical details anymore?

Check out the Blue Antoinette Commerce Cloud, which is built on and abstracts away the complexities of Kubernetes.

http-to-https redirection for Kubernetes Apps on GKE

Problem statement:

At the time of this publication the default ingress HTTP LoadBalancer on Google Kubernetes Engine does not support http-to-https redirection. Furthermore the Kubernetes based configmap of the Click to Deploy solution requires http requests (no https!) to localhost in order to install WordPress (for example).

Therefore a solution is required, which redirects requests from http to https, but also  excludes healthchecks, https requests as well as requests to localhost from http-to-https redirection.

Solution:

This solution describes how to enable http-to-https redirection on the Google Kubernetes Engine (GKE) for the Google Click to Deploy Kubernetes WordPress App. For this solution just the Apache web server and the default ingress HTTP LoadBalancer on GKE, but no Nginx ingress controller is required.

Extend the Kubernetes ConfigMap for .htaccess as follows:

.htaccess: |
 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTP:X-Forwarded-Proto} !https
 RewriteCond %{QUERY_STRING} !healthcheck
 RewriteCond %{HTTP_HOST} !localhost
 RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
 </IfModule>

Change the readinessProbe and livenessProbe path with a custom healthcheck path as follows:

readinessProbe:
  httpGet:
    path: /?healthcheck
    port: 80
    scheme: HTTP
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  successThreshold: 2
  failureThreshold: 5
livenessProbe:
  httpGet:
    path: /?healthcheck
    port: 80
    scheme: HTTP
  initialDelaySeconds: 120

Need further support or Kubernetes Consulting?

Please checkout our Consulting hours.

You don’t want to go into technical details anymore?

Check out the Blue Antoinette Commerce Cloud, which is built on and abstracts away the complexities of Kubernetes.