GCE – SSH Directly Into Your Docker Container

google_cloud_plattform

In this article, I am going to change the SSH port from 22 to 52241 and create a new firewall rule in VPC. Please do your own research and make sure you understand the impact, especially on a production environment.

When you deploy a new docker container on GCE, you can SSH into the host machine ( VM ). This is simply because the IP address is pointing to the host machine. But what about the docker container that runs on it? In this case, you must use docker exec or the gcloud command-line tool in order to get access to the container, which can be pretty time consuming over time.

I am working on a project where I need direct access to my alpine docker container on port 22 or any other port. As you can see in the below output, no ports are exposed for my container.

This is mainly because the docker container shares the network with the host. Source

Containerized VMs launch containers with the network set to host mode. A container shares the host network stack, and all interfaces from the host are available to the container.

This is very convenient because it allows you to access your docker container from pretty much any port. However, only a few ports are actually open and configured in the VPC Network > Firewall settings for security reasons. For the SSH connection I decided to open a custom port 52241. You can do this in your GCP Console under VPC Network > Firewall or with the following gcloud command-line tool.

Once completed, here is how the new firewall rule looks like in the console. If you scroll down, you will also see all affected instances.

GCP Custom Firewall

Before you can SSH into your container on port 52241 you must change the port in the sshd configuration /etc/ssh/sshd_config within your container or container image. Not on the VM.

You may have to restart your ssh service before you can use the new port. Once this is done, you can SSH into your docker container.

AWS – ECS Keeps Recreating Docker Container

AWS ECS Logo

Today was a strange day. I’ve launched a new version of my docker image within an ECS cluster, which usually worked fine. However, today my container always got recreated every 5 minutes for no reason.

ecs_keeps_recreating_containers

The new docker image that I have pushed to the repository had no significant changes, except a redirect from non-SSL ( 80 ) to SSL ( 443 ) for all loaded virtual hosts. So, when I had a look at the processes, everything looked fine. There was nothing that could put the container into an unhealthy status.

Even the log output of the docker container didn’t show any error. After a little bit of research, I ended up on the following AWS developer guide page https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service.html

It was not exactly what I was looking for, but it pretty much explained the problem I had. One of my colleagues said I should maybe have a look at the health checks of the load balancer.

Indeed, when I had a look at the settings in EC2 > Load Balancing > Target Groups > Health Checks the health check expected a success code 200 instead of 301 on port 80. Because of that, the container has been marked unhealthy every 5 minutes.

aws_ec2_load_balancer_health_checks

I hope this will point someone in the right direction.

Download Magento 1 Extensions after M1 EOL

Magento 1 Download Extension

Magento 1 extensions were removed from https://marketplace.magento.com about a month ago. According to Adobe’s recent blog posts, all extensions will be removed early August from their repository, which causes a lot of frustration on developers who are still in the middle of moving towards Magento 2 or simply need the code to translate it into Magento 2 modules.

Source: https://community.magento.com/t5/Magento-DevBlog/How-Extension-Developers-Can-Prepare-for-M1-End-of-Life/ba-p/446216

Source: https://magento.com/blog/magento-news/support-magento-1-software-ends-june-30-2020

So, in order to download an M1 package, you simply have to point to a specific URL. Luckily they didn’t turn off https://connect20.magentocommerce.com yet, but I believe Magento will get rid of it very soon.

I’ve spent a few minutes writing a ” quick and dirty ” PHP script that downloads the most recent version of each extension in https://connect20.magentocommerce.com/community/packages.xml including package details such as name, description, and author. For example https://connect20.magentocommerce.com/community/BankPayment/1.2.0/package.xml

If you download all packages, you will end up with about 1300 extensions.

However, it seems the packages.xml file contains a lot of extensions that are actually not available anymore, that leads to a 404.

Another good resource is https://packages.firegento.com or http://freegento.com/ddl-magento-extension.php to download M1 extensions.

Feel free to change or share the code.