Running a simple web server from any directory

You just need Python installed to run a simple web server from any directory. On Mac Python is already installed. So you just need follow these steps below:

Run these commands in the terminal:

# access the directory
cd /path/to/directory

# start the web server in the port 8000
python -m SimpleHTTPServer 8000

# execute Ctrl+C to kill the web server

Open the browser and access the web server through http://localhost:8000.

Demo

See the demo in the original scale

Set temp directory for NPM scripts running with root user (Docker)

Running scripts through npm with root user will not respect the TMPDIR or any other environment variable used to set the temp directory.

Even this looking like a bug. Actually it is a expected behavior as mentioned in this issue.

So the solution is enable the unsafe-perm flag in the NPM configuration. Since doing this for the global NPM configuration or even in the project scope is quite unsafe because would run anything with root permissions. I think the safest solution is running those commands that depend on the temp directory with the --unsafe-perm argument.

npm run --unsafe-perm <my-npm-script>

Mounting an EBS persistent volume into an EC2 instance with CoreOS

In the last weeks I have been working a lot with AWS. At Bravi we are deploying most of our production services and applications on AWS through the CloudFormation. Which really is a powerful tool to provision the whole infrastructure.

CloudFormation uses templates to specify the stack configuration. This template is a JSON-formatted text file which can be used to create a new stack or apply update changes to an existing stack.

Since it is my first experience with AWS and CloudFormation almost everything is new for me. And some times can take a long time of several attempts to figure out how to configure some stuff that are not really well documented in the AWS website.

That is why I’m going to try post here the solution I found for some of those problems.

I think the first problem I had was mounting an EBS persistent volume into an EC2 instance with CoreOS.

At the end the solution was pretty simple:

  • create the volume using the AWS::EC2::Volume
  • attach the volume into the ec2 instance through the Volumes property
  • add a unit into the cloud-config to format the volume in case it is a new volume
  • add another unit to mount the volume
{
  ...

  "Resources": {
    "EBSVolume" : {
      "Type" : "AWS::EC2::Volume",
      "Properties" : {
        "Size" : "20",
        "AvailabilityZone" : "us-east-1b"
      },
      "DeletionPolicy" : "Snapshot"
    },

    "EC2Instance": {
      "Type": "AWS::EC2::Instance",
      "Properties": {
        "ImageId": { "Ref": "CoreOSAMI" },
        "InstanceType": "t2.small",
        "KeyName": { "Ref": "KeyPair" },
        "NetworkInterfaces": [
          {
            ...
          }
        ],
        "Volumes" : [
          {
            "VolumeId" : { "Ref" : "EBSVolume" },
            "Device" : "/dev/sdb"
          }
        ],
        "UserData" : {
          "Fn::Base64": {
            "Fn::Join": [ "", [
                "#cloud-config\n\n",
                "\n\n",
                "coreos:\n",
                "  update:\n",
                "    reboot-strategy: off\n",
                "  units:\n",
                "    - name: format-ebs-volume.service\n",
                "      command: start\n",
                "      content: |\n",
                "        [Unit]\n",
                "        Description=Formats the ebs volume if needed\n",
                "        Before=docker.service\n",
                "        [Service]\n",
                "        Type=oneshot\n",
                "        RemainAfterExit=yes\n",
                "        ExecStart=/bin/bash -c '(/usr/sbin/blkid -t TYPE=ext4 | grep /dev/xvdb) || (/usr/sbin/wipefs -fa /dev/xvdb && /usr/sbin/mkfs.ext4 /dev/xvdb)'\n",
                "\n",
                "    - name: data.mount\n",
                "      command: start\n",
                "      content: |\n",
                "        [Unit]\n",
                "        Description=Mount EBS Volume to /data\n",
                "        Requires=format-ebs-volume.service\n",
                "        After=format-ebs-volume.service\n",
                "        Before=docker.service\n",
                "        [Mount]\n",
                "        What=/dev/xvdb\n",
                "        Where=/data\n",
                "        Type=ext4\n",
                "\n",
                ""
              ]
            ]
          }
        }
      }
    }
  }
}

CoreOS scheduled tasks

CoreOS uses the Systemd that has built in a bunch of helpful features and tools. For example, instead of using Cron that is the most common way to run scheduled tasks in most of the Linux distributions, Systemd has the Timer unit configuration that schedules the execution of a Service unit.

This past week I had to configure a scheduled backup routine to run everyday at 2 AM. So this examples is what I had to configure on Systemd to run the backup routine daily. The backup script backup-mongodb.sh I have not included in this post because it is just a simple Mongodb backup script.

Basically the simplest way to schedule a service is creating a Timer unit with the same name of the service that is going to be executed by the timer.

Files

backup-mongodb.service

It requires the mongodb.service is running and it runs the backup script.

[Unit]
Description=Backup of mongodb
After=mongodb.service
Requires=mongodb.service

[Service]
ExecStart=/bin/bash /home/core/backup-routines/backup-mongodb.sh

[Install]
WantedBy=local.target

backup-mongodb.timer

It also requires the mongodb.service is running and it triggers the backup-mongodb.service every day at 2 AM. Using Persistent=true persists information on last time the timer was triggered. For more information about Timer take a look in the documentation.

[Unit]
Description=Runs mongodb backup every day at 2 AM
After=mongodb.service
Requires=mongodb.service

[Timer]
OnCalendar=02:00
Persistent=true

[Install]
WantedBy=local.target

Configuring backup schedule

After created those files we just need to load them into the CoreOS machine and start the timer.

BACKUP_NAME="backup-mongodb"

# removes from coreos these configurations in case they already exist there
fleetctl destroy $(fleetctl list-units | grep "^$BACKUP_NAME")

# loads the service and timer units
fleetctl load $BACKUP_NAME.service
fleetctl load $BACKUP_NAME.timer

# starts the timer
fleetctl start $BACKUP_NAME.timer

Status

Looking the list-units you are going to see the timer in active-waiting and the service inactive-dead status. Don’t worry about the service status. The timer is to start it in the configured time.

fleetctl list-units | grep backup-mongodb

UNIT                        ACTIVE          SUB
backup-mongodb.service     inactive        dead
backup-mongodb.timer       active          waiting

6 VIM color schemes

This current week I’m trying to get back to VIM. I was very happy using Sublime this last year. But after more than one year using it without license I wanted to pay for it. But unfortunately U$ 70 I think is too much for a text editor. Therefore this the main reason I’m back to VIM and also I was missing the awesome VIM commands.

After some intensive search for pretty VIM color schemes. These are the 6 schemes I most like:

monokai

Github

monokain

Github

rdark

Github

holokai

Github

ir_black

Github

solarized

Github