Skip to content
This repository has been archived by the owner on Sep 4, 2019. It is now read-only.

ECS Deployment Failing #24

Closed
BitForger opened this issue Jan 3, 2019 · 9 comments
Closed

ECS Deployment Failing #24

BitForger opened this issue Jan 3, 2019 · 9 comments
Assignees
Labels

Comments

@BitForger
Copy link

if [ -z "$(ls -A data/proxies)" ]; then

The above if block is causing all updated deployments of shlink in an ECS environment to fail. I'm trying to figure out why this needs to be run every time on startup as anytime a container is pulled in an orchestrated environment it is likely that it will be pulled and started in a completely clean state. Because of that, the directory it's looking for isn't there while the DB has been initialized and has (or should have) the correct schema. How do I go about making this work for my ECS environment?

@acelaya
Copy link
Member

acelaya commented Jan 3, 2019

Yep, you are probably right.

The operations run in the entry point should be more granular, in order to avoid trying to recreate the database when it already exists.

I will try to provide a fix.

@acelaya acelaya added the bug label Jan 3, 2019
@acelaya acelaya self-assigned this Jan 3, 2019
@BitForger
Copy link
Author

Yep, you are probably right.

The operations run in the entry point should be more granular, in order to avoid trying to recreate the database when it already exists.

I will try to provide a fix.

I should note that it seems to be an issue because I'm using an RDS running MariaDB. I tried to replicate it locally and it seems fine starting up and stopping using the local SQLite implementation.

@acelaya
Copy link
Member

acelaya commented Jan 3, 2019

Yes, the problem will happen only when using an external database, because when using the sqlite one, a new database is created every time you create a container, so it doesn't fail.

If you try to use an existing database with a new container, you will see the error.

@BitForger
Copy link
Author

I believe the best solution is a script to check if the database exists with tables and if so then don't try to re-init everything.

@acelaya
Copy link
Member

acelaya commented Jan 3, 2019

Yep, that's what I had in mind :)

@BitForger
Copy link
Author

I'm writing something in PHP right now, I'll send it over when I'm done.

@acelaya
Copy link
Member

acelaya commented Jan 4, 2019

@BitForger both latest and v1.15.1 are now being rebuilt with the fix applied. They should be ready in 30min-1hour (probably less, but docker hub is slow building images, so just in case).

@BitForger
Copy link
Author

I'm seeing another issue when trying to redeploy using my own copies.. if it happens in those builds i'll open another ticket.

@acelaya
Copy link
Member

acelaya commented Jan 4, 2019

I have just checked that both builds have finished successfully. You should be able to pull both latest and v1.15.1 with the new entry point.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants