I'm trying to push a Laravel installation from development to a live-environment on a Laravel Forge-server. When pushing, I'm getting an error, that I'm not getting on my local environment.
I can't figure out, how I connect directly to the provisioned server (through FTP or SFTP), to change single files manually (to debug).
Which means that in order to try something, then I need to make a new commit and an entirely new deployment, for every thing I want to test. Quite tedious and it clutters my git history!
... I can't even do a commit --amend, since that gives me the error:
fatal: refusing to merge unrelated histories
Attempt 1) I can't find anything about it in the Forge knowledge base.
Attempt 2) I've found several articles talking about a good guide, but that guide gives an error 404:
It's this one: https://freek.dev/2016/03/let-your-clients-use-sftp-on-a-forge-provisioned-server/
Am I missing something obvious? Or is the commit-n-push really the way to go? Is this normal for automated deployment systems?
For others who find this question, then Forge-support got back to me really quickly and linked to this blogpost, explaining how to get sftp-access to a Forge-provisioned server
What I did wrong, was that I didn't use the username: forge (I was using my email).
Related
I tried to deploy a keystone app to Heroku and I did it but while I tried to open the app I got the following error:
An error occurred handling a request for the Admin UI: Error: Prisma error: The table main.User does not exist in the current database.
Here's a screenshot containing more details about the error:
I tried to locate the database and create the User table.
I expect to know the steps of how to solve this issue.
It looks like your DB hasn't been initialised properly. The error you've included is failing to count the items in the User list which (if you don't have sessions configured) is likely the first query to run – a count of items in each list is shown on the Admin UI the landing page so that's the first thing it does.
So something about how your migrations are being generated or applied in production isn't setup right. Most of the relevant docs on how this works are in the CLI guide, specifically, see the section about database migrations and the db.useMigrations flag.
Having db.useMigrations turned off can be handy if you're just playing around in dev. Keystone will automatically sync your DB structure to what's defined in your list configs whenever it starts, and does so without creating any physical migration files. If you're prototyping some change or just mucking around, this may be what you want but – if you're deploying somewhere – better to turn db.useMigrations on. Then, if Keystone detects changes to the DB when it runs, it'll prompt you to create a migration file, which can be tweaked to protect existing data if needed, tracked under version control (eg. git) and deployed.
Getting these migrations to run in an environment like Heroku is a little slightly weird as (assuming it's enabled for your app) Heroku can auto-scale. Migrations on the other hand need to be run exactly once. You also can't just lock the DB and run migrations when the first instance of the app starts – this delays the start up of the HTTP server so, if the migrations run for too long, Heroku may think the deployment has failed.
The way we suggest getting around this is to run migrations in the build staging. Fans of the 12-factor app methodology will notice this violated the separation of build and release stages but, for a simple Heroku deploy, it works fine. For larger/more serious apps, creating and applying migrations usually an area that needs significant thought and attention. The specific infrastructure and rollout processes required will be project dependant.
I'd also encourage you to check out the Keystone 6 Heroku example codebase if you haven't already. It's a little out of date but it shows the migrations and package.json scripts in action.
I know that https://forge.laravel.com/auth/register is available for $12/month*, but I'd like to understand how to accomplish the same thing myself.
What I assume is possible (and what I'm looking for): I create a server that has only Ubuntu 18.04.3 installed and nothing else, and I upload a script that installs all the appropriate software and sets up MySQL with the correct passwords, etc (without manual intervention).
I've tried Laradock and had tons of problems with Docker and don't want to do that anymore.
I see that https://cloud.digitalocean.com/droplets/new lets me create a LEMP droplet (Ubuntu, Nginx, MySQL, PHP-FPM) with one click. But it lacks Redis, and its versions are outdated (e.g. PHP 7.2).
I've heard people mention Chef (maybe this?), but that seems to be more complicated than what I'm imagining.
Unfortunately I'm not even sure how to search for what I'm trying to do (or how to tag this question); is this called "server provisioning"? I've been searching phrases like "automatic install script redis mysql server for laravel".
Thanks in advance for pointing me in the right direction.
* I also just found https://getcleaver.com/ and https://runcloud.io/server-management, which each look like Forge + Envoyer (and RunCloud offers a free plan).
It is called server provisioning and Chef would be a good fit for this, check out Ansible too - another thing you could do is setup the server yourself and create an image from that server and then base your new servers out of that image, that way you'll have all your services installed from the start.
This sounds like a job or something like Puppet (or Chef/Ansible), however Laravel Envoy may be another tool to look at if you haven't already for the second part of your problem.
I highly recommend Heroku (or similar service), as this is all done out of the box, and has a ton of other great features that make developing a pipeline a breeze.
I had an experience with slow sqlalchemy subquery using syntax Query.select_from(). Based on this experience, I want to get warning everytime certain syntax is used in our codebase. For example, when programmers add this code bellow, I want to get warnings.
q = session.query(Address).select_from(User).\
join(User.addresses).\
filter(User.name == 'ed')
Is there any linter or tools that can do this?
Ideally, you would set a pre-receive hook on the remote Git repo hosting server, like this one, in order to read the pushed files and grep for "query.*\.select_from": if detected, that hook would reject the push.
If you don't have access to the remote server (for instance GitHub), you would need to set a webhook instead.
The alternative is to deploy a pre-push hook to all clients, and do the check there, but that could be bypassed, or could be not deployed to everybody.
A server side hook / webhook is safer.
I'm fairly new to server administration. I have my Laravel app up and running and I want to make sure it has proper backups. I have researched some backup packages and I have settled on https://github.com/spatie/laravel-backup.
However, once the server fails, I need to know how to use the most recent backup (which will be on AWS S3) to restore the database on the rebuilt server. Are there any suggestions for guides on how to do this? I can't seem to find any unless it doesn't really require much learning and instead just a couple mySQL commands.
Thanks!
I would use replication and within Laravel i would try to switch connection to the replica database server so things can run smoothly until the problem is resolved.
Take a look at this Cross-Region Replication
A typical production environment is automatically running backups on most important things that your deployment needs in order to recover from a failure. Those parts would commonly be your database and storage folder, and configuration files.
Also when you deploy a laravel application there aren't many things that are "worth" backing up , you can choose the entire disk to be mirrored somewhere or you can schedule a backup script which run every N times and backups the things that are more important to your application.
Personally i wouldn't rely on an package from laravel to handle my backups , you can always use other backup utilities, replication and so on.
Update
Take a look at the link below:
User Guide » Amazon RDS DB Instance Lifecycle » Backing Up and Restoring
Backing Up and Restoring
You can call the API function RestoreDBInstanceFromDBSnapshot as showed on example.
But i don't think something automated exists that would auto restore or magically make everything work, you need to do a lot of security checks if something like that would even be attempted. Final word i believe a good solution manually entering or sending the request would be the most solid solution.
I tried to deploy my project with capifony, becouse I found here an answer, that with capifony deployment is easy. Well I don't think it is, so my question is:
How can I deploy my project via ftp, I put all my files on the server but even if I browse to web/app.php, the only thing I get is an empty page, whatever route I write in the url. So someone please explain me how can I get this work! Thank you!
A couple of things to think of when deploying a Symfony2 project to a new server or computer (as far as I've encountered) might be:
Make sure that the server and it's PHP installation meets the Symfony2 requirements (and perhaps also the recommendations)
Check that you've somewhat followed the installation instructions (found here)
Try to clear the cache
Make sure that the web server and it's PHP process have write permissions to the cache folder
If none of these helps, try to modify the app_dev.php to temporarily allow access from your current (client) IP (instead of restraining it to localhost). Then, hopefully, you'll get a more useful and detailed error message, instead of the blank page (which often is caused by some fatal error that have occurred during the initialization of the framework and its kernel)
Update: Noticed now that you've tagged your question with 'windows', but that you don't mention which server you're trying to deploy to. I wrote the above with some *nix based server in mind, but hopefully some of it are applicable to Windows servers too (but there might be other common sources of error running under Windows that I'm not familliar with