Settu upp Plesk á CentOS 7
Að nota annað kerfi? Plesk er sérstakt stjórnborð fyrir vefþjón sem gerir notendum kleift að stjórna persónulegum og/eða viðskiptavinum vefsíðum sínum, gagnagrunnum
Buildbot er opinn uppspretta, Python byggt, stöðugt samþættingartæki til að gera sjálfvirkan hugbúnaðargerð, prófun og uppsetningu. Buildbot samanstendur af einum eða fleiri Buildbot meistara og fjölda starfsmanna. Buildbot master eða Buildmaster hefur miðlæg stjórn á kerfinu. Það er ábyrgt fyrir stjórnun byggingarumhverfisins, starfsmanna og tekur allar ákvarðanir um að senda störf til starfsmanna. Buildmaster skynjar breytingar á kóðageymslunni og sendir skipanirnar eða störfin til starfsmanna til að framkvæma. Starfsmenn framkvæma verkin og skila niðurstöðunni til Buildmaster. Buildmaster lætur síðan hönnuði vita í gegnum margar studdar rásir. Í þessari kennslu munum við setja upp Buildbot meistara og starfsmann á CentOS 7. Við munum einnig stilla auðkenningu og Nginx sem öruggan öfugt umboð.
Fyrir þessa kennslu munum við nota 192.168.1.1
sem opinbera IP tölu og ci.example.com
sem lénið sem vísaði í átt að Vultr tilvikinu. Vinsamlega vertu viss um að skipta út öllum tilfellum af dæmi léninu og IP tölunni fyrir það raunverulega.
Uppfærðu grunnkerfið þitt með því að nota handbókina Hvernig á að uppfæra CentOS 7 . Þegar kerfið þitt hefur verið uppfært skaltu halda áfram að setja upp PostgreSQL.
Settu upp Pip, sem er pakkastjóri fyrir Python.
sudo yum -y install epel-release
sudo yum -y install python-pip gcc python-devel git
sudo pip install --upgrade pip
Buildbot styður margar gerðir af gagnagrunnsþjónum eins og MySQL, PostgreSQL og SQLite. Í þessari kennslu munum við nota PostgreSQL til að hýsa Buildbot gagnagrunnsþjóninn.
PostgreSQL er gagnagrunnskerfi sem tengist hlutum, þekkt fyrir stöðugleika og hraða. Sjálfgefin yum
geymsla inniheldur gamla útgáfu af PostgreSQL, svo bættu við PostgreSQL geymslunni.
sudo yum -y install https://download.postgresql.org/pub/repos/yum/10/redhat/rhel-7-x86_64/pgdg-centos10-10-1.noarch.rpm
Settu upp PostgreSQL gagnagrunnsþjóninn.
sudo yum -y install postgresql10-server postgresql10-contrib postgresql10
Frumstilla gagnagrunninn.
sudo /usr/pgsql-10/bin/postgresql-10-setup initdb
Ræstu PostgreSQL þjóninn og gerðu það kleift að ræsast sjálfkrafa við ræsingu.
sudo systemctl start postgresql-10
sudo systemctl enable postgresql-10
Breyttu lykilorðinu fyrir sjálfgefinn PostgreSQL notanda.
sudo passwd postgres
Skráðu þig inn sem PostgreSQL notandi.
sudo su - postgres
Búðu til nýjan PostgreSQL notanda fyrir Buildbot.
createuser bb_user
Þú getur notað hvaða notendanafn sem er í staðinn fyrir bb_user
, ef þú vilt. PostgreSQL veitir psql
skelina til að keyra fyrirspurnir í gagnagrunninum. Skiptu yfir í PostgreSQL skelina.
psql
Stilltu lykilorð fyrir nýstofnaðan notanda.
ALTER USER bb_user WITH ENCRYPTED password 'DBPassword';
Skiptu út DBPassword
fyrir öruggt lykilorð.
Búðu til nýjan gagnagrunn fyrir Buildbot uppsetninguna.
CREATE DATABASE buildbot OWNER bb_user;
Farið úr psql
skelinni.
\q
Skiptu yfir í sudo
notanda.
exit
Breyttu pg_hba.conf
skránni til að virkja MD5 byggða auðkenningu.
sudo nano /var/lib/pgsql/10/data/pg_hba.conf
Finndu eftirfarandi línur og breyttu gildunum peer
og ident
, í METHOD
dálkinum, í trust
og md5
, í sömu röð.
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 ident
# IPv6 local connections:
host all all ::1/128 ident
Eftir uppfærslu mun uppsetningin líta út eins og eftirfarandi texti.
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# IPv6 local connections:
host all all ::1/128 md5
Vistaðu skrána og farðu úr ritlinum. Settu upp PostgreSQL gagnagrunnsmillistykkið fyrir Python.
sudo pip install psycopg2
Endurræstu PostgreSQL svo breytingarnar geti tekið gildi.
sudo systemctl restart postgresql-10
Settu upp Buildbot með Pip.
sudo pip install 'buildbot[bundle]' pyopenssl service_identity
Ofangreind skipun mun setja upp Buildbot ásamt buildbot-www
, buildbot-worker
, og nokkrum vefviðbótum eins og buildbot-waterfall-view
.
Til að tryggja að Buildbot hafi verið sett upp með góðum árangri geturðu staðfest með því að athuga útgáfu Buildbot.
buildbot --version
Úttakið ætti að líkjast eftirfarandi texta.
[user@vultr ~]$ buildbot --version
Buildbot version: 0.9.15.post1
Twisted version: 17.9.0
Breyttu eldveggsreglunum þínum til að leyfa höfn 8010
. Buildbot notar þessa höfn til að hlusta á vefbeiðnirnar.
sudo firewall-cmd --zone=public --add-port=8010/tcp --permanent
sudo firewall-cmd --reload
Búðu til nýjan notanda án forréttinda til að keyra Buildbot meistara- og starfsferla. Ekki er mælt með því að keyra Buildbot master þjónustu sem root
notandi.
sudo adduser buildbot
sudo passwd buildbot
Skráðu þig inn sem nýstofnaður buildbot
notandi.
sudo su - buildbot
Settu upp Buildbot masterinn í /home/buildbot/master
möppunni. Þessi mappa mun innihalda stillingar, stöðu og annálaskrár fyrir hverja byggingu.
buildbot create-master --db 'postgresql://bb_user:DBPassword@localhost/buildbot' ~/master
Gakktu úr skugga um að skipta um skilríki gagnagrunnsnotandans í skipuninni hér að ofan.
Athugið: Ef þú vilt nota SQLite gagnagrunn í stað PostgreSQL skaltu einfaldlega sleppa --db 'postgresql://bb_user:DBpassword@localhost/buildbot'
valkostinum. SQLite gagnagrunnurinn verður búinn til í sömu möppu.
The above command will create the ~/master
directory to store the Buildmaster files. It will also write the data into the PostgreSQL database. You will get the following output.
[buildbot@vultr ~]$ buildbot create-master --db 'postgresql://bb_user:DBPassword@localhost/buildbot' ~/master
mkdir /home/buildbot/master
creating /home/buildbot/master/master.cfg.sample
creating database (postgresql://bb_user:DBPassword@localhost/buildbot)
buildmaster configured in /home/buildbot/master
Copy the sample configuration file to a live configuration file.
cp ~/master/master.cfg.sample ~/master/master.cfg
Edit the configuration file.
nano ~/master/master.cfg
Find the following lines.
c['workers'] = [worker.Worker("example-worker", "pass")]
...
c['builders'].append(
util.BuilderConfig(name="runtests",
workernames=["example-worker"],
factory=factory))
...
c['title'] = "Hello World CI"
c['titleURL'] = "https://buildbot.github.io/hello-world/"
...
c['buildbotURL'] = "http://localhost:8010/"
...
c['db'] = {
'db_url' : "postgresql://bb_user:DBpassword@localhost/buildbot",
}
The above configuration has an entry for a sample worker. We will modify the sample entry for the worker we will be running on localhost
. Change the example-worker
to any suitable name for the localhost
worker and change the pass
to some other password. Make a note of the worker name and password as we will require that later in the tutorial. Change the name of the worker in the list of builders. Change the name of the application and project URL according to your needs.
Change the Buildbot URL from localhost
to your actual domain name or public IP address. Also, verify that the database information in the configuration file matches your actual database credentials.
At the end of the file, add c['buildbotNetUsageData'] = None
. This parameter will disable sending the software version information and plugin usage details to the developers. However, to enable sending the uses information, change the option to Full
.
The configuration should look like the following text.
c['workers'] = [worker.Worker("localhost-worker", "Password123")]
...
c['builders'].append(
util.BuilderConfig(name="runtests",
workernames=["localhost-worker"],
factory=factory))
...
c['title'] = "My Application CI"
c['titleURL'] = "https://example.com/my-app"
...
c['buildbotURL'] = "http://192.168.1.1:8010/"
...
c['db'] = {
'db_url' : "postgresql://bb_user:DBpassword@localhost/buildbot",
}
...
c['buildbotNetUsageData'] = None
Save the file and exit the editor. Check the configuration file for errors.
buildbot checkconfig ~/master
If the configuration file has no errors, you will see following output.
[buildbot@vultr ~]$ buildbot checkconfig ~/master
Config file is good!
Now that everything is configured correctly, you can start the Buildbot master.
buildbot start ~/master
You will see the following output.
[buildbot@vultr ~]$ buildbot start ~/master
Following twistd.log until startup finished..
The buildmaster appears to have (re)started correctly.
Now that the Buildbot master has started correctly, the web user interface is accessible at http://192.168.1.1:8010
. You should see the following Buildbot interface.
Since we have already modified the worker configuration in ~/master/master.cfg
, we can proceed to create a new worker.
buildbot-worker create-worker ~/worker localhost localhost-worker Password123
Make sure that you use the exact same worker name and password as mentioned in ~/master/master.cfg
file. If there's a mismatch in worker name or password, the worker will not be able to connect to the Buildbot master. You will see the following output upon successful execution.
[buildbot@vultr ~]$ buildbot-worker create-worker ~/worker localhost example-worker pass
mkdir /home/buildbot/worker
mkdir /home/buildbot/worker/info
Creating info/admin, you need to edit it appropriately.
Creating info/host, you need to edit it appropriately.
Not creating info/access_uri - add it if you wish
Please edit the files in /home/buildbot/worker/info appropriately.
worker configured in /home/buildbot/worker
Information about the worker is stored in the /info
directory. Edit the administrative information about the developer.
nano ~/worker/info/admin
Replace the example name with your actual name and email.
Your Name <[email protected]>
Now, open the file containing information about the host.
nano ~/worker/info/host
Replace the example instruction with the actual information about the host system.
Localhost, CentOS 7
The worker admin and host information is only used to tell the users about the system. You can also add additional information about the system such as Buildbot version and Twisted version.
Start the worker.
buildbot-worker start ~/worker
The output will look like the following text.
[buildbot@vultr ~]$ buildbot-worker start ~/worker
Following twistd.log until startup finished..
The buildbot-worker appears to have (re)started correctly.
To check if the worker is registered, head to the web interface of Buildbot and navigate to Builds >> Workers
from the left navigation. You should see that the worker is up and ready to build.
To run a sample build, to check if the Buildbot worker is running successfully, navigate to Builds >> Builders
. Click on the runtests
builder name to open the builder interface and click on the Force
button to force a build. Provide your name and click on the Start Build
button to start the build. Since it is a sample build test to check the Buildbot environment, it will finish in a couple of seconds. You will get a success message and the build result.
Although the Buildbot master and worker can be easily started using the commands above, it is recommended to use Systemd units to run and manage the Buildbot services. This will ensure that they are automatically started on system restart and failures.
Note: Switch to the sudo
user again by running either exit
or su <username>
. From now on all the commands need to be executed by the sudo
user.
Stop the running Buildbot worker and master service.
sudo su buildbot -c "buildbot stop /home/buildbot/master"
sudo su buildbot -c "buildbot-worker stop ~/worker"
Create a new Systemd unit file for the Buildbot master.
sudo nano /etc/systemd/system/buildbot.service
Populate the file.
[Unit]
Description=BuildBot master service
After=network.target
[Service]
Type=forking
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/master
ExecStart=/usr/bin/buildbot start
ExecStop=/usr/bin/buildbot stop
ExecReload=/usr/bin/buildbot restart
[Install]
WantedBy=multi-user.target
Start the Buildbot master and enable it to automatically start at boot time.
sudo systemctl start buildbot
sudo systemctl enable buildbot
Create a new Systemd unit file for the Buildbot worker.
sudo nano /etc/systemd/system/buildbot-worker.service
Populate the file.
[Unit]
Description=BuildBot worker service
After=network.target
[Service]
Type=forking
User=buildbot
Group=buildbot
WorkingDirectory=/home/buildbot/worker
ExecStart=/usr/bin/buildbot-worker start
ExecStop=/usr/bin/buildbot-worker stop
ExecReload=/usr/bin/buildbot-worker restart
[Install]
WantedBy=multi-user.target
Start the Buildbot worker and enable it to automatically start at boot time.
sudo systemctl start buildbot-worker
sudo systemctl enable buildbot-worker
You can check the status of the services.
sudo systemctl status buildbot buildbot-worker
If the services are running smoothly, you will see that in the output.
[user@vultr ~]$ sudo systemctl status buildbot buildbot-worker
● buildbot.service - BuildBot master service
...
Active: active (running) since Fri 2018-01-12 16:00:59 UTC; 1min 25s ago
...
Jan 12 16:00:59 vultr.guest systemd[1]: Started BuildBot master service.
● buildbot-worker.service - BuildBot worker service
...
Active: active (running) since Fri 2018-01-12 16:02:00 UTC; 24s ago
...
Jan 12 16:02:00 vultr.guest systemd[1]: Started BuildBot worker service.
By default, authentication is not enabled in the Buildbot web interface. For internet facing sites, it is strongly recommended to setup authentication so that only the authorized users can have the ability to perform administrative tasks. To set up authentication, reopen the Buildbot master configuration file.
sudo su buildbot -c "nano /home/buildbot/master/master.cfg"
Add the following lines to the end of the file.
c['www']['authz'] = util.Authz(
allowRules = [
util.AnyEndpointMatcher(role="admins")
],
roleMatchers = [
util.RolesFromUsername(roles=['admins'], usernames=['admin_user'])
]
)
c['www']['auth'] = util.UserPasswordAuth({'admin_user': 'AdminPassword'})
Replace both occurrences of admin_user
with the actual username you want to use and AdminPassword
with a strong password.
Check for errors in the configuration file.
sudo su buildbot -c "buildbot checkconfig /home/buildbot/master"
Restart Buildbot master service so that the changes can take effect.
sudo systemctl restart buildbot
Browse the web interface again to see that the anonymous users can only view the basic details about the build server. Now, log in using the credentials set in the master.cfg
file and you will see that all other administrative functions are only available to the logged in admin user.
By default, Buildbot listens to the port 8010
on unsecured connections. Securing the web interface with HTTPS
is recommended to ensure that the data is safe during transportation from the browser to the server. In this section of the tutorial, we will install and secure Nginx with Let's Encrypt free SSL certificates. The Nginx web server will work as a reverse proxy to forward the incoming requests to Buildbot's HTTP endpoint.
Install Nginx.
sudo yum -y install nginx
Start Nginx and enable it to automatically start at boot time.
sudo systemctl start nginx
sudo systemctl enable nginx
Install Certbot, which is the client application for Let's Encrypt CA.
sudo yum -y install certbot
Before you can request the certificates, you will need to allow ports 80
and 443
or standard HTTP
and HTTPS
services through the firewall. Also, remove port 8010
, which listens to the unsecured connections.
sudo firewall-cmd --zone=public --add-service=http --permanent
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --zone=public --remove-port=8010/tcp --permanent
sudo firewall-cmd --reload
Note: To obtain certificates from Let's Encrypt CA, the domain for which the certificates are to be generated must be pointed towards the server. If not, make the necessary changes to the DNS records of the domain and wait for the DNS to propagate before making the certificate request again. Certbot checks the domain authority before providing the certificates.
Generate the SSL certificates.
sudo certbot certonly --webroot -w /usr/share/nginx/html -d ci.example.com
Líklegt er að útbúin vottorð séu geymd í /etc/letsencrypt/live/ci.example.com/
skránni. SSL vottorðið verður geymt sem fullchain.pem
og einkalykillinn verður geymdur sem privkey.pem
.
Við skulum dulkóða vottorð renna út eftir 90 daga, þess vegna er mælt með því að setja upp sjálfvirka endurnýjun skírteina með Cron störf.
Opnaðu cron vinnuskrána fyrir root
notandann.
sudo crontab -e
Bættu við eftirfarandi línu í lok skráarinnar.
30 5 * * * /usr/bin/certbot renew --quiet
Ofangreint cron starf mun keyra á hverjum degi klukkan 5:30. Ef skírteinið á að renna út mun það endurnýja það sjálfkrafa.
Nú skaltu breyta Nginx sjálfgefna stillingarskránni til að taka út default_server
línuna.
sudo sed -i 's/default_server//g' /etc/nginx/nginx.conf
Búðu til nýja stillingarskrá fyrir Buildbot vefviðmót.
sudo nano /etc/nginx/conf.d/buildbot.conf
Fylltu út skrána.
upstream buildbot {
server 127.0.0.1:8010;
}
server {
listen 80 default_server;
server_name ci.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl http2 default_server;
server_name ci.example.com;
root html;
index index.html index.htm;
ssl on;
ssl_certificate /etc/letsencrypt/live/ci.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/ci.example.com/privkey.pem;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1440m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains;";
access_log /var/log/nginx/buildbot.access.log;
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-Host $host;
location / {
proxy_pass http://buildbot;
}
location /sse/ {
proxy_buffering off;
proxy_pass http://buildbot/sse/;
}
location /ws {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_pass http://buildbot/ws;
proxy_read_timeout 6000s;
}
}
Athugaðu hvort villurnar eru í nýju stillingarskránni.
sudo nginx -t
Ef þú sérð eftirfarandi úttak er uppsetningin villulaus.
[user@vultr ~]$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
Ef þú hefur fengið einhvers konar villu, vertu viss um að athuga slóðina að SSL vottorðunum. Endurræstu Nginx vefþjóninn til að innleiða breytinguna á uppsetningu.
sudo systemctl restart nginx
Opnaðu Buildmaster stillingarskrána.
sudo su buildbot -c "nano /home/buildbot/master/master.cfg"
Finndu eftirfarandi línu.
c['buildbotURL'] = "http://192.168.1.1:8010/"
Breyttu slóðinni í samræmi við lénið sem þú notar.
c['buildbotURL'] = "https://ci.example.com/"
Endurræstu Buildbot master þjónustuna.
sudo systemctl restart buildbot
Nú geturðu fengið aðgang að Buildbot mælaborðinu á https://ci.example.com
. Þú munt sjá að tengingarnar við Buildbot eru nú tryggðar með SSL.
Skráðu þig inn með því að nota stjórnandaskilríki og bættu við fyrstu leiðslunni þinni til að byrja að byggja upp forritið þitt.
Að nota annað kerfi? Plesk er sérstakt stjórnborð fyrir vefþjón sem gerir notendum kleift að stjórna persónulegum og/eða viðskiptavinum vefsíðum sínum, gagnagrunnum
Smokkfiskur er vinsælt, ókeypis Linux forrit sem gerir þér kleift að búa til framsendingarforrit á vefnum. Í þessari handbók muntu sjá hvernig á að setja upp Squid á CentOS til að snúa þér
Inngangur Lighttpd er gaffal af Apache sem miðar að því að vera miklu minna auðlindafrekt. Hann er léttur, þess vegna heitir hann, og er frekar einfaldur í notkun. Uppsetning
VULTR hefur nýlega gert breytingar á enda þeirra og allt ætti nú að virka vel út úr kassanum með NetworkManager virkt. Ef þú vilt slökkva á
Icinga2 er öflugt eftirlitskerfi og þegar það er notað í aðal-viðskiptavinamódel getur það komið í stað þörf fyrir NRPE-undirstaða vöktunareftirlit. Húsbóndinn
Að nota annað kerfi? Apache Cassandra er ókeypis og opinn uppspretta NoSQL gagnagrunnsstjórnunarkerfi sem er hannað til að veita sveigjanleika, háan
Að nota annað kerfi? Microweber er opinn uppspretta draga og sleppa CMS og netverslun. Microweber frumkóði er hýst á GitHub. Þessi handbók mun sýna þér
Að nota annað kerfi? Mattermost er opinn uppspretta, sjálfhýst valkostur við Slack SAAS skilaboðaþjónustuna. Með öðrum orðum, með Mattermost, þú ca
Það sem þú þarft Vultr VPS með að minnsta kosti 1GB af vinnsluminni. SSH aðgangur (með rót / stjórnunarréttindi). Skref 1: Uppsetning BungeeCord Fyrst af öllu
Plesk stjórnborðið er með mjög fallegri samþættingu fyrir Lets Encrypt. Lets Encrypt er ein af einu SSL veitunum sem gefa út skírteini að fullu
Lets Encrypt er vottunaryfirvöld sem sérhæfir sig í að útvega SSL vottorð án endurgjalds. cPanel hefur byggt upp snyrtilega samþættingu svo þú og viðskiptavinurinn þinn
Að nota annað kerfi? Concrete5 er opinn uppspretta CMS sem býður upp á marga áberandi og gagnlega eiginleika til að aðstoða ritstjóra við að framleiða efni auðveldlega og
Að nota annað kerfi? Review Board er ókeypis og opinn hugbúnaður til að skoða frumkóða, skjöl, myndir og margt fleira. Það er vefbundið hugbúnaðarstríð
Í þessari handbók munt þú læra hvernig á að setja upp HTTP auðkenningu fyrir Nginx vefþjón sem keyrir á CentOS 7. Kröfur Til að byrja þarftu að
YOURLS (Your Own URL Shortener) er opinn uppspretta vefslóða styttingar og gagnagreiningarforrit. Í þessari grein munum við fjalla um ferlið við uppsetningu
Using a Different System? Introduction ArangoDB is an open source NoSQL database with a flexible data model for documents, graphs, and key-values. It is
Inngangur /etc/ skrárinn gegnir mikilvægu hlutverki í því hvernig Linux kerfi virkar. Ástæðan fyrir þessu er sú að næstum allar kerfisstillingar
Margir kerfisstjórar stjórna miklu magni af netþjónum. Þegar aðgangur þarf að skrám á mismunandi netþjónum er innskráning á hvern og einn fyrir sig ca
Þessi kennsla mun fjalla um ferlið við að setja upp Half Life 2 leikjaþjón á CentOS 6 System. Skref 1: Forsendur settar upp Til að setja upp ou
Laravel GitScrum, eða GitScrum er opinn uppspretta framleiðniverkfæri hannað til að hjálpa þróunarteymi að innleiða Scrum aðferðafræðina á svipaðan hátt
Gervigreind er ekki í framtíðinni, hún er hér í nútímanum Í þessu bloggi Lestu hvernig gervigreindarforrit hafa haft áhrif á ýmsa geira.
Ertu líka fórnarlamb DDOS árása og ruglaður með forvarnaraðferðirnar? Lestu þessa grein til að leysa spurningar þínar.
Þú gætir hafa heyrt að tölvuþrjótar græða mikið af peningum, en hefur þú einhvern tíma velt því fyrir þér hvernig þeir vinna sér inn svona peninga? við skulum ræða.
Viltu sjá byltingarkenndar uppfinningar frá Google og hvernig þessar uppfinningar breyttu lífi hvers manns í dag? Lestu síðan til að blogga til að sjá uppfinningar frá Google.
Hugmyndin um að sjálfkeyrandi bílar fari á göturnar með hjálp gervigreindar er draumur sem við höfum átt um tíma núna. En þrátt fyrir nokkur loforð eru þau hvergi sjáanleg. Lestu þetta blogg til að læra meira…
Þar sem vísindin þróast hratt og taka yfir mikið af viðleitni okkar, eykst hættan á því að verða fyrir óútskýranlegri einstæðu. Lestu, hvað sérkenni gæti þýtt fyrir okkur.
Geymsluaðferðir gagna hafa verið að þróast gæti verið frá fæðingu gagna. Þetta blogg fjallar um þróun gagnageymslu á grundvelli upplýsingamynda.
Lestu bloggið til að þekkja mismunandi lög í Big Data Architecture og virkni þeirra á einfaldasta hátt.
Í þessum stafræna heimi hafa snjallheimilistæki orðið afgerandi hluti af lífi. Hér eru nokkrir ótrúlegir kostir snjallheimatækja um hvernig þau gera líf okkar þess virði að lifa því og einfaldara.
Nýlega gaf Apple út macOS Catalina 10.15.4 viðbótaruppfærslu til að laga vandamál en svo virðist sem uppfærslan sé að valda fleiri vandamálum sem leiða til múrsteins á Mac vélum. Lestu þessa grein til að læra meira