Invalid value for field resource.machineType in Google Compute Engine

google_cloud_plattform

Currently I am working on a light-weight PHP class which should help me to create, list and delete VM instances on Googles Compute Engine. While writing the class, I came across few issue I would like to share with you. In the following example I tried to create a micro instance, because didn’t need much computing power. As you probably know, here is how you can select the machine type via dashboard.

google_cloud_compute_engine_micro_machine

When I tried to create a micro instance via PHP API with the correct Machine Type I received the following error message.

Here is a part of a PHP file I am using for API connection tests.

As you can see, I set a string f1-micro which is obviously not valid. I double-checked the API guides and found this URL.

So I defined the value for the machine type as follows which has fixed the invalid value for field resource.machineType.

 

AWS RDS – You Need (at least one of) The SUPER Privilege(s)

Today I had the opportunity to move a local Magento database to an Amazon RDS. Based on the well-documented article Creating a DB Instance Running the MySQL Database Engine I was optimistic to finish the migration pretty soon. But as you know, there is always something that goes wrong.

After creating the database instance class ( db.m3.large ) I have decided to proceed with some test imports before I change any database credentials in Magento.

Good decision because the first import didn’t run through.

I was able to fix the problem by adding the missing parameter log_bin_trust_function_creators as explained here. Before the next import I had to delete the database and create a new one.

Unfortunately there was another problem with a DEFINER which tried to create a trigger as a different user. On Amazon RDS only a user with SUPER privileges can do that. Therefore, I had to remove the DEFINER from the MySQL schema you see below.

That’s it. Now I was able to import my DB on Amazon RDS without errors.

 

Nginx Docker Container and getpwnam(“www-data”) problem

I am using nginx:1.10.1-alpine to run Nginx as a docker container. Today I have replaced the Nginx container and always got the status Restarting (1) Less than a second ago after starting the container.

With the command docker logs nginx I got the following error logs.

The error message basically means that the user www-data which I have defined in /etc/nginx/nginx.conf doesn’t exists in /etc/passwd. That makes sense, because nginx:1.10.1-alpine comes with a minimal setup. I my case I need the user www-data for other linked php-fpm containers. To fix the problem I just added the missing user during the container build.

Voilà.

Nginx and Cached CSS / JS files

Yesterday I had a pretty hard time with cached CSS / JS files on my developer environment. I supposed to review layout changes, but I always got the old CSS files. I have spent about 2 hours to find the reason. At the end the solution was to turn off the syscall sendfile in my virtual host configuration.

If you use Nginx as a reverse proxy to serve pages from an application server, you can leave sendfile turned off.

 

Reload Nginx Inside Docker Container

I am using docker for Nginx which is running with multiple virtual hosts. Sometimes I have to reload my updated nginx configurations, but I don’t want restart the container each time. Here is how you can reload your nginx without any downtime and without interrupting any connections.

1. Find your container name

Use docker ps to find your nginx container.

2. Reload Nginx

With docker exec -it {container_name} {command} you can directly access your container and execute commands. In my case the name of the container is nginx-server.