Laravel auth, sentry.io and one server down

Weeks go by but never look alike. Last week I was a little bit tired of working on Podmytube.com. It’s quite exhausting to have one day job and one evening job to work on every day and I decided to make a small break. Everything is running quite well, podcasts are up to date, I am in no hurry for any feature … time was well chosen.

So I decided to try some new tools or projects I’ve in my todo list for some time.

Laravel auth.

This laravel feature allow one project to take advantage of one full authentication process very quickly. When you begin one laravel project, a simple php artisan make:auth followed by one php artisan migrate and your web application get one user registration, login and reset password part.

When you run this, by default, once registered, one user should be logged. My problem is that, on my first laravel project (podmytube dashboard by the way), actually it’s not the case.

Once registration complete, and user have to log to access his/her dashboard. On any other Laravel project I started since, registration (and sign in) is working fine but for this particular app, I failed to find one proper solution. This “bug” is annoying me for a long time and I wanted to fix it. I took some time to handle this but I still failed to fix it.

I’ve posted one question in stack overflow but still no answer.

Sentry.io

Since january, I’ve subscribed to some US developer’s podcast like syntax, build your saas, laracasts, Taylor Otwell laravel snippets, and full stack radio. And each of them spoke at least once of sentry.io. So I decided to give it a try.

Sentry, as they are describing the products

is open-source error tracking that provides visibility across your entire stack, giving you the details you need to fix your bugs.

What I heard from the podcasts sponsoring I heard on every podcast was that sentry.io allow you to get one stack trace of what lead to an error.

Laravel implementation was quite easy and well documented. Add the package with Composer composer require sentry/sentry-laravel:1.0.2 then add Sentry reporting to App/Exceptions/Handler.php :

public function report(Exception $exception)
{
    if (app()->bound('sentry') && $this->shouldReport($exception)){
        app('sentry')->captureException($exception);
    }

    parent::report($exception);
}

Create the Sentry configuration file (config/sentry.php) with this command:

php artisan vendor:publish --provider="Sentry\Laravel\ServiceProvider"

Finish by adding one SENTRY_LARAVEL_DSN to your .env

SENTRY_LARAVEL_DSN=https://<key>@sentry.io/<project>

And you are done with that. For the moment … no problem and they are having one “developer plan” which is free under 5000 events (at this time). Weather was sunny … til I wanted to deploy the update on production server …

Server down

Actually, when I want to deploy one version on production server, I make

  • git checkout master && git merge <MY_DEV_BRANCH>.
  • docker exec -it <CONTAINER_NAME> phpunit.
  • If everything is green “ssh production
  • Go into the directory to update and type git pull.
  • Running tests again docker exec -it <CONTAINER_NAME> phpunit.
  • Go to bed 🙂

This time I was stopped on the ssh part with one “connection error” that hurt me plenty.

Oh shit what’s happening again

First thing to check, is server really down or is it me ?

  • Check if Google is live, ok.
  • Check if Podmytube service is live too, ok. Podcasts are up to date too. Stress is going low.
  • Ok ssh only seems down.

Once checked that SSH only was down and customers not affected I was relieved. I’ve tried some commands (restart (still no ssh), restart with ovh rescue mode (ssh ok), restart to normal mode (still no ssh). I opened a ticket and went to bed.

On the next morning ssh was back and everything was back to normal. I was not really worried. Every part of Podmytube is living within a docker container. If ssh was still down yesterday (yes, problems occurs on saturday too), I would have subscribed to another hosting service and deployed the containers. It would have taken at max 2 hours to get service back (with one mid day database backup). Nothing to panic about !

Someday, I’m glad this “side project” is within the podcast universe which does not require instant processing 🙂

See you next monday !

Published by

Fred

Totally fluent in frenglish, what a gift !

Leave a Reply

Your email address will not be published. Required fields are marked *