Group items tagged

Encrypted cookies are an important security feature in Laravel.

All of this encryption and decryption is handled in Laravel by the Encrypter using PHP's built-in security tools, including OpenSSL.

Passwords are not encrypted, they are hashed.

Crypt (symmetric encryption) and Hash (one-way cryptographic hashing).

Laravel uses this same method for cookies, both the sender and receiver, using APP_KEY as the encryption key.

something like user passwords, you should never have a way to decrypt them. Ever.

Unique: The collision rate (different inputs hashing to the same output) should be very small

Laravel hashing implements the native PHP password_hash() function, defaulting to a hashing algorithm called bcrypt.

a one-way hash, we cannot decrypt it. All that we can do is test against it.

User password storage should never be reversible, and therefore doesn’t need APP_KEY at all.

Any good credential management strategy should include rotation: changing keys and passwords on a regular basis

update the key on each server.

their sessions invalidated as soon as you change your APP_KEY.

make and test a plan to decrypt that data with your old key and re-encrypt it with the new key.

A null queue driver is also included which discards queued jobs.

In your config/queue.php configuration file, there is a connections configuration option.

any given queue connection may have multiple "queues" which may be thought of as different stacks or piles of queued jobs.

each connection configuration example in the queue configuration file contains a queue attribute.

if you dispatch a job without explicitly defining which queue it should be dispatched to, the job will be placed on the queue that is defined in the queue attribute of the connection configuration

pushing jobs to multiple queues can be especially useful for applications that wish to prioritize or segment how jobs are processed

specify which queues it should process by priority.

If your Redis queue connection uses a Redis Cluster, your queue names must contain a key hash tag.

ensure all of the Redis keys for a given queue are placed into the same hash slot

all of the queueable jobs for your application are stored in the app/Jobs directory.

Job classes are very simple, normally containing only a handle method which is called when the job is processed by the queue.

we were able to pass an Eloquent model directly into the queued job's constructor. Because of the SerializesModels trait that the job is using, Eloquent models will be gracefully serialized and unserialized when the job is processing.

When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database.

The handle method is called when the job is processed by the queue

The arguments passed to the dispatch method will be given to the job's constructor

delay the execution of a queued job, you may use the delay method when dispatching a job.

dispatch a job immediately (synchronously), you may use the dispatchNow method.

specify a list of queued jobs that should be run in sequence.

Deleting jobs using the $this->delete() method will not prevent chained jobs from being processed. The chain will only stop executing if a job in the chain fails.

this does not push jobs to different queue "connections" as defined by your queue configuration file, but only to specific queues within a single connection.

To specify the queue, use the onQueue method when dispatching the job

To specify the connection, use the onConnection method when dispatching the job

defining the maximum number of attempts on the job class itself.

to defining how many times a job may be attempted before it fails, you may define a time at which the job should timeout.

using the funnel method, you may limit jobs of a given type to only be processed by one worker at a time

using the throttle method, you may throttle a given type of job to only run 10 times every 60 seconds.

If an exception is thrown while the job is being processed, the job will automatically be released back onto the queue so it may be attempted again.

dispatch a Closure. This is great for quick, simple tasks that need to be executed outside of the current request cycle

When dispatching Closures to the queue, the Closure's code contents is cryptographically signed so it can not be modified in transit.

Laravel includes a queue worker that will process new jobs as they are pushed onto the queue.

once the queue:work command has started, it will continue to run until it is manually stopped or you close your terminal

they will not notice changes in your code base after they have been started.

during your deployment process, be sure to restart your queue workers.

customize your queue worker even further by only processing particular queues for a given connection

The --once option may be used to instruct the worker to only process a single job from the queue

The --stop-when-empty option may be used to instruct the worker to process all jobs and then exit gracefully.

Daemon queue workers do not "reboot" the framework before processing each job.

Since queue workers are long-lived processes, they will not pick up changes to your code without being restarted.

php artisan queue:restart

The queue uses the cache to store restart signals

the queue workers will die when the queue:restart command is executed, you should be running a process manager such as Supervisor to automatically restart the queue workers.

each queue connection defines a retry_after option. This option specifies how many seconds the queue connection should wait before retrying a job that is being processed.

The --timeout option specifies how long the Laravel queue master process will wait before killing off a child queue worker that is processing a job.

When jobs are available on the queue, the worker will keep processing jobs with no delay in between them.

While sleeping, the worker will not process any new jobs - the jobs will be processed after the worker wakes up again

the numprocs directive will instruct Supervisor to run 8 queue:work processes and monitor all of them, automatically restarting them if they fail.

Laravel includes a convenient way to specify the maximum number of times a job should be attempted.

define a failed method directly on your job class, allowing you to perform job specific clean-up when a failure occurs.

a great opportunity to notify your team via email or Slack.

php artisan queue:retry all

php artisan queue:flush

When injecting an Eloquent model into a job, it is automatically serialized before being placed on the queue and restored when the job is processed

when you do Queue::push() you're actually calling the push method on the queue driver you're using

instruct Laravel to create an instance of your application and start executing jobs, this instance will stay alive indefinitely which means the action of starting your Laravel application happens only once when the command was run & the same instance will be used to execute your jobs

This will start an instance of the application, process a single job,

Using queue:listen ensures that a new instance of the app is created for every job, that means you don't have to manually restart the worker in case you made changes to your code, but also means more server resources will be consumed.

the queue:listen command runs the WorkCommand inside a loop

The connection this worker will be pulling jobs from

The queue the worker will use to find jobs

Auto DevOps works with any Kubernetes cluster;

using the Docker or Kubernetes executor, with privileged mode enabled.

Base domain (needed for Auto Review Apps and Auto Deploy)

Kubernetes (needed for Auto Review Apps, Auto Deploy, and Auto Monitoring)

Prometheus (needed for Auto Monitoring)

scrape your Kubernetes cluster.

project level as a variable: KUBE_INGRESS_BASE_DOMAIN

A wildcard DNS A record matching the base domain(s) is required

Once set up, all requests will hit the load balancer, which in turn will route them to the Kubernetes pods that run your application(s).

review/ (every environment starting with review/)

staging

production

need to define a separate KUBE_INGRESS_BASE_DOMAIN variable for all the above based on the environment.

Continuous deployment to production: Enables Auto Deploy with master branch directly deployed to production.

Continuous deployment to production using timed incremental rollout

Automatic deployment to staging, manual deployment to production

Auto Build creates a build of the application using an existing Dockerfile or Heroku buildpacks.

If a project’s repository contains a Dockerfile, Auto Build will use docker build to create a Docker image.

Each buildpack requires certain files to be in your project’s repository for Auto Build to successfully build your application.

Auto Test automatically runs the appropriate tests for your application using Herokuish and Heroku buildpacks by analyzing your project to detect the language and framework.

Auto Code Quality uses the Code Quality image to run static analysis and other code checks on the current code.

Static Application Security Testing (SAST) uses the SAST Docker image to run static analysis on the current code and checks for potential security issues.

Dependency Scanning uses the Dependency Scanning Docker image to run analysis on the project dependencies and checks for potential security issues.

License Management uses the License Management Docker image to search the project dependencies for their license.

Vulnerability Static Analysis for containers uses Clair to run static analysis on a Docker image and checks for potential security issues.

Review Apps are temporary application environments based on the branch’s code so developers, designers, QA, product managers, and other reviewers can actually see and interact with code changes as part of the review process. Auto Review Apps create a Review App for each branch. Auto Review Apps will deploy your app to your Kubernetes cluster only. When no cluster is available, no deployment will occur.

The Review App will have a unique URL based on the project ID, the branch or tag name, and a unique number, combined with the Auto DevOps base domain.

Your apps should not be manipulated outside of Helm (using Kubernetes directly).

Dynamic Application Security Testing (DAST) uses the popular open source tool OWASP ZAProxy to perform an analysis on the current code and checks for potential security issues.

Auto Browser Performance Testing utilizes the Sitespeed.io container to measure the performance of a web page.

add the paths to a file named .gitlab-urls.txt in the root directory, one per line.

After a branch or merge request is merged into the project’s default branch (usually master), Auto Deploy deploys the application to a production environment in the Kubernetes cluster, with a namespace based on the project name and unique project ID

Auto Deploy doesn’t include deployments to staging or canary by default, but the Auto DevOps template contains job definitions for these tasks if you want to enable them.

For internal and private projects a GitLab Deploy Token will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved.

If the GitLab Deploy Token cannot be found, CI_REGISTRY_PASSWORD is used. Note that CI_REGISTRY_PASSWORD is only valid during deployment.

If present, DB_INITIALIZE will be run as a shell command within an application pod as a helm post-install hook.

a post-install hook means that if any deploy succeeds, DB_INITIALIZE will not be processed thereafter.

DB_MIGRATE will be run as a shell command within an application pod as a helm pre-upgrade hook.

Once your application is deployed, Auto Monitoring makes it possible to monitor your application’s server and response metrics right out of the box.

annotate the NGINX Ingress deployment to be scraped by Prometheus using prometheus.io/scrape: "true" and prometheus.io/port: "10254"

While Auto DevOps provides great defaults to get you started, you can customize almost everything to fit your needs; from custom buildpacks, to Dockerfiles, Helm charts, or even copying the complete CI/CD configuration into your project to enable staging and canary deployments, and more.

Auto DevOps uses Helm to deploy your application to Kubernetes.

make use of the HELM_UPGRADE_EXTRA_ARGS environment variable to override the default values in the values.yaml file in the default Helm chart.

specify the use of a custom Helm chart per environment by scoping the environment variable to the desired environment.

Your additions will be merged with the Auto DevOps template using the behaviour described for include

copy and paste the contents of the Auto DevOps template into your project and edit this as needed.

In order to support applications that require a database, PostgreSQL is provisioned by default.

Set up the replica variables using a project variable and scale your application by just redeploying it!

You should not scale your application using Kubernetes directly.

Some applications need to define secret variables that are accessible by the deployed application.

Auto DevOps pipelines will take your application secret variables to populate a Kubernetes secret.

Environment variables are generally considered immutable in a Kubernetes pod.

If STAGING_ENABLED is defined in your project (e.g., set STAGING_ENABLED to 1 as a CI/CD variable), then the application will be automatically deployed to a staging environment, and a production_manual job will be created for you when you’re ready to manually deploy to production.

If CANARY_ENABLED is defined in your project (e.g., set CANARY_ENABLED to 1 as a CI/CD variable) then two manual jobs will be created: canary which will deploy the application to the canary environment production_manual which is to be used by you when you’re ready to manually deploy to production.

If INCREMENTAL_ROLLOUT_MODE is set to manual in your project, then instead of the standard production job, 4 different manual jobs will be created: rollout 10% rollout 25% rollout 50% rollout 100%

To start a job, click on the play icon next to the job’s name.

not all buildpacks support Auto Test yet

When a project has been marked as private, GitLab’s Container Registry requires authentication when downloading containers.

Authentication credentials will be valid while the pipeline is running, allowing for a successful initial deployment.

We strongly advise using GitLab Container Registry with Auto DevOps in order to simplify configuration and prevent any unforeseen issues.