EC2: Laravel migrations run as many times as the instances

up vote
3
down vote

favorite

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.
– Sheng Slogar
Nov 13 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.
– thitami
Nov 14 at 9:38

add a comment |

up vote
3
down vote

favorite

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.
– Sheng Slogar
Nov 13 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.
– thitami
Nov 14 at 9:38

add a comment |

up vote
3
down vote

favorite

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

We experience a very weird issue at the moment. Our tech stack involves AWS Elastic Beanstalk,EC2 and Laravel deploying the code with Bitbucket Pipelines.

The problem is that whenever we include a migration in the deploy then it's run twice (as many times as our EC2 instances in this environment!).

Our scripts are located under .ebextensions dir:

option_settings:

  "aws:elasticbeanstalk:container:php:phpini":

    document_root: /public

container_commands:

    01initdb:

        command: "php artisan migrate"

We ended up breaking our deploy a few times because the system can't tell that this migration has already run.

Anyone saw this issue before?

Update
We came up with this implementation as MySQL connection is refused if we add
php artisan migrate in the build script.

laravel amazon-web-services amazon-ec2

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

edited Nov 13 at 15:07

asked Nov 13 at 14:34

thitami

381728

asked Nov 13 at 14:34

thitami

381728

asked Nov 13 at 14:34

thitami

381728

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.
– Sheng Slogar
Nov 13 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.
– thitami
Nov 14 at 9:38

add a comment |

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.
– Sheng Slogar
Nov 13 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.
– thitami
Nov 14 at 9:38

I haven't used Laravel with AWS but php artisan:migrate relies on a migrations table to know which migrations were run and which weren't. As long as this table is properly being shared across instances, running it multiple times shouldn't cause any collisions... unless you're coming across a race condition.
– Sheng Slogar
Nov 13 at 18:38

@ShengSlogar Exactly, there is a migrations which keeps track of the latter. That's my suspicion too. A race condition between the instances ending up causing a problem in the deployment.
– thitami
Nov 14 at 9:38

add a comment |

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

add a comment |

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53283329%2fec2-laravel-migrations-run-as-many-times-as-the-instances%23new-answer', 'question_page');
}
);

Post as a guest

Name

Required, but never shown

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

add a comment |

up vote
2
down vote

accepted

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

add a comment |

up vote
2
down vote

accepted

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

There are many ways to do this:

Have a single ops server run all the tasks that need to be run on only 1 server. Your bitbucket pipeline can trigger this ops server for single server tasks and the others for multi-server tasks.

Create a custom Artisan command that attains locks (DB or cache) to run migrations while avoiding parallel runs / race conditions.

Trigger deployments serially (dont know if that's possible on Beanstalk).

As the OP mentioned, setting the leader_only: true flag on Elastic Beanstalk scripts to only run the command on a single instance does the trick!

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

edited Nov 14 at 16:16

answered Nov 13 at 19:30

Paras

5,412735

answered Nov 13 at 19:30

Paras

5,412735

answered Nov 13 at 19:30

Paras

5,412735

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

add a comment |

2

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

Thanks for the great suggestions, @Paras! I have applied the leader_only: true flag on the Elastic Beanstalk scripts which is most probably another solution.
– thitami
Nov 14 at 9:40

Thanks for sharing @thitami, I've updated my answer to include your solution. Seems like the best one of the lot! :)
– Paras
Nov 14 at 16:16

add a comment |

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

Some of your past answers have not been well-received, and you're in danger of being blocked from answering.

Please pay close attention to the following guidance:

Please be sure to answer the question. Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.

Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfrgtkky