1,130 experience to go until the next level!
In case you were wondering, you earn Laracasts experience when you:
Earned once you have completed your first Laracasts lesson.
Earned once you have earned your first 1000 experience points.
Earned when you have been with Laracasts for 1 year.
Earned when you have been with Laracasts for 2 years.
Earned when you have been with Laracasts for 3 years.
Earned when you have been with Laracasts for 4 years.
Earned when you have been with Laracasts for 5 years.
Earned when at least one Laracasts series has been fully completed.
Earned after your first post on the Laracasts forum.
Earned once 100 Laracasts lessons have been completed.
Earned once you receive your first "Best Reply" award on the Laracasts forum.
Earned if you are a paying Laracasts subscriber.
Earned if you have a lifetime subscription to Laracasts.
Earned if you share a link to Laracasts on social media. Please email [email protected] with your username and post URL to be awarded this badge.
Earned once you have achieved 500 forum replies.
Earned once your experience points passes 100,000.
Earned once your experience points hits 10,000.
Earned once 1000 Laracasts lessons have been completed.
Earned once your "Best Reply" award count is 100 or more.
Earned once your experience points passes 1 million.
Earned once your experience points ranks in the top 50 of all Laracasts users.
Replied to Long-running Processes And Visibility
Well, the bash scripts would not be executed on a public web server per se.
The bash scripts start life as blade template files that I inject variables into during my "provisioning" step, which then get compiled and stored in a variable, then Laravel connects to the game server host machine and dumps the variable contents into a
.sh file. The laravel app then executes the bash script in a detached state and disconnects from the shell session, since these scripts can take 15-20 minutes to run sometimes (downloading game files.)
The risk is fairly low, these game server host machines are all small VPSs that are marshaled for the sole purpose of hosting game servers, so the risk is limited, not to detract from your very valid criticism.
My problem with this approach is I have no visibility into the status of the bash scripts, I just have to cross my fingers and wait to see if the game server comes up (or shell in myself).
Started a new conversation Long-running Processes And Visibility
Hey guys, I've been inspired by the laravel ecosystem into building a personal game server management system for this stupid e-sports hobby.
For some reason I've got it in my head that I want to use PHP for shelling into host machines to handle the provisioning and deployment of these game servers.
I've come up with three distinct plans and made action on each, but when it gets hard I second guess myself with doubts and confusion which make me pick another route and it's an ugly vicious cycle.
Please help me :}
Laravel app uploads a bash script onto the remote server, executes that script then bails on the session.
Create a secondary "extended" queue connection that I can put known long-running messages on and otherwise just keep abusing Laravel into doing my dirty work like I always do.
Use some message queue to send the chore to a ReactPHP loop (like the one in laravel-websockets) that handles all of the SSH-y stuff.
All three options work, I've made all three of them work, but making them work well is a lot of freaking work and I just want to pick one and move onto the vicious cycle and get out of this one.
Edit for what is probably important context. This is a personal project that I would only expect to be maintaining a very limited number of game host servers. It's not meant to be a one-size-fits-all server management tool like Forge or your typical "game server panel", I just want something that will alert me if there's a problem rather than me hoping the game server comes up.